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(54) Title: SECRET-KEY CERTIFICATES 



(57) Abstract 

Cryptographic methods 
and apparatus arc disclosed that 
enable formation and issuance of 
secret-key certificates. In contrast 
the well-known cryptographic 
technique of public-key 
certificates, where a public -key 
certificate is a digital signature 
of a certification authority on a 
public key, pairs consisting of 
a public key and a corresponding 
secret-key certificate can be 
generated by anyone. However, 
triples consisting of a secret 
key, a matching public key 
and a secret-key certificate 
corresponding to the public key, 
can only be generated when the 
certification authority is involved. 
Also described are applications 
of secret-key certificates to 
public-key directories and to 
restrictive blind issuing protocols. 
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SBCRBT-KgY CERTIFICATES 



BACKGROUND OF THE INVENTION 

1. Field of the invention. 

5 The present invention relates to cryptographic techniques, 

and more particularly to methods and apparatus for 
implementing certificate schemes based on public-key 
cryptography . 

2. Description of the prior art. 

10 Public-key certificates, usually plainly referred to as 

certificates, are an important cryptographic tool for secure 
key management. The idea is to have a specially appointed 
party, commonly called the Certification Authority, certify 
the public keys of other parties in the system by digitally 

15 signing these public keys with its own secret key. By widely 
distributing the public key of the Certification Authority 
through a variety of media, anyone can be assured that it is 
genuine. Because a public-key certificate is a digital 
signature of the Certification Authority on a public key, 

20 certificates on public keys of other parties can be verified 
by anyone by using the public key of the Certification 
Authority. The net effect is that impersonation attacks, and 
similar other attacks, are prevented. 

In practical applications, the certificates of the 

25 Certification Authority may, and perhaps should, certify 
additional information. Along with the public key, a 
certificate could validate such information as the name of the 
party associated with the public key, employer, telephone 
number, electronic mail address, and a list of access rights. 

30 To facilitate practicality of the certificate issuing 

process, public keys can be certified recursively, according 
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to a hierarchical structure. For example, in an electronic 
cash system, the main bank can certify the public keys of all 
the local banks, the local banks in turn can certify public 
keys in POS terminals by using their certified keys, and the 
5 secret keys corresponding to the public keys in the POS 

terminals can be used to decrypt information that is sent by 
the host. The hierarchic certification process can be thought 
of as building a tree, each node containing a public key and a 
certificate on the public key. A certificate on a public key 
10 in a node is a digital signature on that public key, that has 
been computed by the party associated with the parent node by 
applying the secret key that corresponds to the public key of 
the parent node. Anyone can verify the validity of a public 
key by recursively descending (or ascending) the tree from the 
15 root node to the node associated with the public key that is 
being verified (or vice versa) . A certification hierarchy 
that is often suggested is one that is implied by the lifetime 
of the cryptographic keys: keys that are more susceptible to 
attacks are changed more frequently, and are certified by keys 
20 that have a longer lifetime. 

Public keys can be listed in so-called public-key 
directories, which can be made available on CD-ROM or other 
media. In order to encrypt a message intended for another 
party, one merely needs to look up the public key of that 
25 other party in the public-key directory, verify the validity 
of the certificate, and encrypt the message with the public 
key. It can then be sent to the other party. No interaction 
is needed between the two parties. In this way for instance 
encrypted electronic mail can be sent over a computer network. 
30 Because the certificate mechanism obviates the need for the 
public-key directory to be secured, public keys need not 
necessarily be listed in a public-key directory. They may be 
sent (along with the certificate) on request, by the party 
associated with the public key itself, or by any other party 
35 that need not be trusted, such as a server in a computer 
network. 

In cryptographic mechanisms for transfer of credentials, the 
Certification Authority at issuing time can issue a 
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certificate on a public key of a user. The type of credential 
that is issued can, for instance, be denoted by the type of 
signature that the Certification Authority computes. This 
allows the user, when transferring the credential to a 

5 recipient, to make a digital signature on a message of the 

recipient (describing such information as the identity of the 
recipient and transaction details) , by using the secret key 
corresponding to his certified public key. The certificate 
proves the validity of the credential to the recipient, 

10 whereas the signature made by the user proves that the user 
willingly transferred the credential to the recipient. 

For privacy-protected transfer of credentials, the 
information that is issued by the Certification Authority 
should not be linkable to executions of the issuing protocol. 

15 Special techniques are known that enable the user to blind the 
issuing protocol while interacting with the Certificate 
Authority. 

While important and useful, the public-key certificate 
technique also has a few problems associated with it. First 

20 of . these relates to privacy. It is conceivable that providers 
for a variety of electronic systems available in the near 
future will require participants to meet certain criteria 
before certifying their public keys. These criteria may 
include social status, income, type of job, trustworthiness, 

25 and so on. Because a public-key certificate is a digital 
signature of the Certification Authority on the public key, 
pairs consisting of a public key and a corresponding 
public-key certificate reveal to anyone which parties are 
participating in a certain system, and which parties are not 

30 participating. This reveals which parties meet the criteria 
specified by the Certification Authority, and which parties 
may not meet them. Likewise, the genuineness of the- 
additional information (employer, telephone number, access 
rights, and so on) that may have been certified along' with the 

35 public key, is revealed. Consequently, public-key 

certificates allow anyone to extract profiles of other 
parties, by scanning for their appearances, or the lack 
thereof, in compiled lists of certified public keys (such as 
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public-key directories) . This problem is by no means removed 
by letting participants send their public keys only on 
request, instead of using a public-key directory. 

A second problem is that the publication of a public -key 
5 directory reveals a huge amount of digital signatures of the 
Certification Authority on known, or chosen, public keys. 
Although most of the known digital signature schemes are 
believed to be secure under known, or (adaptively) chosen, 
message attacks, only a few signature schemes are known that 
10 can be proven to be secure, assuming the existence of 
functions that are substantially unfeasible to invert. 
Unfortunately, these schemes are currently not practical for 
large-scale use. Since public-key directories typically will 
contain an enormous amount of entries, the Certification 
15 Authority will have to use an efficient signature scheme. 

This implies that the signatures in the public-key directory 
may be helpful in attempts to break the signature scheme of 
the Certification Authority; they can be used to mount known 
or (adaptively) chosen message attacks. Again, this problem 
20 is not removed by letting participants send their public keys 
only on request, instead of using a public-key directory. 

A third problem is in blinding public-key certificate 
issuing protocols in mechanisms for privacy-protected transfer 
of credentials (see, for instance, U.S. Patent No. 4,759,063 
25 to Chaum for a discussion of the technique of blinding in 
public-key cryptography) . In many circumstances, the 
Certification Authority does not want the users to be able to 
blind to their hearts' contents, but would like to encode 
information in the issued information that cannot be changed 
30 by the blinding operations of the user. For instance, in 

mechanisms for transferring credentials under pseudonym, this 
encoded information can be uniquely associated with the user 
that the credential is issued to, thereby linking the 
pre-images of all the pseudonyms of each user. In this way, 
35 it can be ensured that users cannot use the credentials of 

other users, even if they cooperate. For credentials that may 
be shown only a limited number of times, such as coins in an 
electronic cash system, it can be arranged that this encoded 
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information is revealed if and only if the credential is shown 
a number of times exceeding a predetermined limit. This 
obviates the need for on-line verification of these 
credentials. For such purposes, an issuing protocol is needed 

5 in which the Certification Authority issues a secret key, a 
public key, and a public-key certificate, in such a way that 
the public key and the certificate can be blinded by the user, 
but a non-constant function of the secret key cannot. Such an 
issuing protocol is called a restrictive blind signature 

10 issuing protocol, and is described and claimed in patent 

application Ser. No. PCT/NL94/00179 , filed August 1, 1994, and 
is incorporated by reference herein. From the point of view 
of security, no satisfactory constructions of restrictive 
blind signature issuing protocols are known in which the 

15 certificate is a public-key certificate. This is a serious 
problem, since restrictive blind signature issuing protocols 
are of crucial importance for the construction of efficient 
and secure mechanisms for privacy-protected off-line transfer 
of credentials. 

20 Patent application Ser. No. PCT/NL94/00179 , filed August 1, 
1994, also describes and claims an inventive method for 
constructing restrictive blind signature issuing protocols 
where the issued certificate is not a digital signature on the 
public key (and hence not a public-key certificate) . As is 

25 demonstrated in detail, the construction of efficient and 

secure restrictive blind signature issuing protocols becomes 
much easier by removing the need for the certificate to be a 
signature of the issuer on the public key. Most (more 
specifically, all but the last one described) of the exemplary 

30 restrictive blind signature issuing protocols described and 
claimed in patent application Ser. No. PCT/NL94 / 0017 9 are 
constructed by applying this inventive method. 

While the inventive method described and claimed in patent 
application Ser. No. PCT/NL94 / 00179 overcomes the third 

35 problem associated with public-key certificates, it does not 
address the first two problems. This invention describes a 
generalized method that overcomes all three problems 
associated with public-key certificates. 
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OBJECTS OF THE INVENTION 

Accordingly, it is an object of the present invention to 
allow anyone to generate pairs consisting of a public key and 
a corresponding certificate, while at the same time ensuring 
5 that it is unfeasible to generate, without knowledge of a 

special secret key that is held by a Certification Authority, 
triples consisting of a secret key, a matching public key, and 
a corresponding certificate, by providing for a new kind of 
certificates that will henceforth be called secret-key 
10 certificates. 

Another object of the present invention is to prevent lists 
of certified public keys, such as public-key directories, from 
revealing the genuineness of privacy-related information, by 
using secret-key certificates instead of public-key 
15 certificates. 

A further object of the present invention is to prevent 
lists of certified public keys, such as public-key 
directories, from revealing information that may be helpful in 
known or chosen message attacks on the signature scheme of the 
20 Certification Authority, by using secret-key certificates 
instead of public-key certificates. 

Yet another object of the present invention is to describe 
techniques to construct secret-key certificates, and issuing 
protocols therefor, from well-known digital signature schemes 
25 that are commonly referred to in the art as Fiat/Shamir type 
signature schemes (see, Fiat, A. and Shamir, A. , 
" How to prove yourself: practical solutions to identification 
and signature problems , " Crypto *86, Spr inger-Verlag (1987), 
pp. 186-194) . 

30 A still further object of the present invention is to 

construct efficient and secure restrictive blind secret-key 
certificate issuing protocols, by le tting the Certificatio n 

Au t h o ri^ty-— ars-s-ue— fcs iples consisting of a secret ke y:, a-j na_t.chin g 

public ke y\, and a_ c orresponding secret-key certificate, such 

35 that the public key and the certificate can be blinded by the 
receiving party, but at least part of the secret key cannot be 
blinded. 
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An even further object of the present invention is to 
implement hierarchical certification by recursive application 
of secret-key certificates instead of public-key certificates. 
Still another object of the present invention is to allow 
> efficient, economical, and practical apparatus and methods 
fulfilling the other objects of the invention. 

Other features, objects, and advantages of this invention 
will be appreciated when the description and appended claims 
are read in conjunction with the figures. 

10 BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 shows a representative combination block and 
functional diagram of an exemplary secret-key certificate 
system in accordance with the teachings of the present 
invention . 

15 Figure 2 shows a flowchart of a secret-key .certificate 

issuing protocol for a first preferred embodiment in 

accordance with the teachings of the present invention. 
Figure 3 shows a flowchart of a secret-key certificate 

issuing protocol, such that the Certification Authority does 
20 not need to know the secret key of the recipient, for the 

first preferred embodiment in accordance with the teachings of 

the present invention. 

Figure 4 shows a flowchart of a secret-key certificate 

issuing protocol, such that the subliminal channel in the 
25 secret-key certificate is prevented, for the first preferred 

embodiment in accordance with the teachings of the present 

invention . 

Figure 5 shows a flowchart of a secret-key certificate 
issuing protocol, such that the recipient fully blinds the 
30 issued information, for the first preferred embodiment in 
accordance with the teachings of the present invention. 

Figure 6 shows a first flowchart of a restrictive blind 
secret-key certificate issuing protocol for the first 
preferred embodiment in accordance with the teachings of the 
35 present invention. 

Figure 7 shows a second flowchart of a restrictive blind 
secret-key certificate issuing protocol for the first 
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preferred embodiment in accordance with the teachings of the 
present invention . 

Figure 8 shows a flowchart of a secret-key certificate 
issuing protocol for a second preferred embodiment in 

5 accordance with the teachings of the present invention. 

Figure 9 shows a flowchart of a secret-key certificate 
issuing protocol, such that the Certification Authority does 
not need to know the secret key of the recipient, for the 
second preferred embodiment in accordance with the teachings 

10 of the present invention. 

Figure 10 shows a flowchart of a secret-key certificate 
issuing protocol, such that the subliminal channel in the 
secret-key certificate is prevented, for the second preferred 
embodiment in accordance with the teachings of the present 

15 invention. 

Figure 11 shows a flowchart of a secret-key certificate 
issuing protocol, such that the recipient fully blinds the 
issued information, for the second preferred embodiment in 
accordance with the teachings of the present invention. 
20 Figure 12 shows a flowchart of a restrictive .blind 
secret-key certificate issuing protocol for the second 
preferred embodiment in accordance with the teachings of the 
present invention . 

SUMMARY OF THE INVENTION 

25 In accordance with these and other objects of this 

invention, a brief summary of the invention is presented. 
Some simplifications and omissions may be made in the 
following summary, which is intended to highlight and 
introduce some aspects of the present invention, but not to 

30 limit its scope. Detailed descriptions of preferred exemplary 
embodiments adequate to allow those of ordinary skill in the 
art to make and use this invention will be provided later. 

In essence, the primary purpose of a public-key certificate 
is to certify the tasks that a participant in a cryptographic 

35 system can successfully perform with respect to his public 
key, rather than the public key itself. Consider the three 
most well-known public-key cryptographic tasks in a 
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cryptographic system: digital signing, identification, and 
encryption. The intended purpose of a certificate is to 
certify that the tasks of digital signing, proving knowledge 
of a secret key that corresponds to a public key, and 
5 decrypting a message that is encrypted with a public key, are 
performed using a secret key the usage of which has been 
permitted by the Certification Authority. In other words, it 
is the secret key that must be certified, not necessarily the 
public key. 

10 Informally, a secret-key certificate is a digital signature 
of the Certification Authority on a secret key, such that it 
is not a digital signature on the public key that matches the 
secret key. More precisely, triples consisting of a secret f 
key, a matching public key, and a corresponding secret-key 
15 certificate can be feasibly generated only by the 

Certification Authority, but pairs consisting of a public key 
and a corresponding secret-key certificate can be feasibly I 
generated by anyone. 

In a public-key directory, parties are listed together with 
20 their public keys and corresponding certificates. If the 

certificates are secret-key certificates, then the information 
in the directory does not reveal discriminating information 
about legitimate participation, as each of the entries could 
have been generated by anyone (if the directory is, or has 
25 been at a certain point in time, open for public writing) . If 
additional information is included as well, such as telephone 
numbers, postal address, and access rights, then this may be 
bogus information as well. To ensure that users will be 
unable to tell whether entries in a public-key directory have 
30 been certified by the Certification Authority or not, the 

manufacturer of a public-key directory on, say, a CD-ROM, can 
gather the entries in the Directory by letting the parties 
associated with the public keys submit their own public keys 
and associated secret-key certificates, as they wish them to 
35 appear on the CD-ROM. 

For the same reason, the information listed in the directory 
cannot be of much help in attacking the signature scheme of 
the Certification Authority. In particular, it can be of no 
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help whatsoever if pairs consisting of a public key and a 
corresponding secret-key certificate can be generated, without 
cooperation of the Certification Authority, with a probability 
distribution that is indistinguishable from the probability 
5 distribution that applies when the certificate issuing 
protocol is performed with the Certification Authority. 

An attacker whose keys have not been certified by the KAC 
would need to know the secret keys of legitimate participants 
in the system in order to have any advantage in breaking the 
10 signature scheme of the Certification Authority over trying to 
break it from scratch. Revealing one's secret key brings 
along a great deal of trust in that it will not be misused, 
and so in practice the consequence of using secret-key 
certificates instead of public-key certificates is that 
15 attacks to break the signature scheme of the KAC will be much 
harder to mount . 

Secure public-key cryptographic schemes, such as schemes for 
the aforementioned tasks of proving knowledge of a secret key 
corresponding to a public key, signing a message with a secret 
20 key corresponding to a public key, and decrypting a message 
encrypted with a public key, are feasible to perform only if 
one actually knows the secret key corresponding to the public 
key. Hence, the fact that a user can successfully perform 
such a task attests to the fact that he knows the secret key 
25 corresponding to his public key, and this in turn proves that 
the certificate must have been issued by the Certification 
Authority. 

The following illustrations are helpful to appreciate the 
use of secret-key certificates: 

30 1. Suppose that a first party wants to transfer an 

encrypted message to a second party. From the public-key 
directory, the first party retrieves the public key of the 
second party, and a corresponding secret-key certificate, 
which supposedly has been issued by the Certification 

35 Authority. The first party encrypts its message using the 

public key of the second party, and transfers it to the second 
party. Although the first party does not know whether the 
information listed in the public-key directory is genuine or 
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not, it is ensured that if the second party can decrypt and 
retrieve the original message, then the Certification 
Authority computed the string listed in the public-key 
directory. Obviously, a proper response of the second party 
5 to the first party will allow the first party to distinguish 
between the two cases . 

2. Suppose that the second party digitally signs a message 
for the first party. Given the message, the digital signature 
of the second party, and the information listed with the 

10 second party in the public-key directory, the first party is 
able to verify not only that the digital signature is genuine, 
but it is also ensured that it was indeed made with a 
certified key. Of course, if this signature is to have any 
legal significance, then anyone should be able to verify these 

15 two facts . 

3 . Suppose that the second party wishes to obtain a 
secret-key certificate, issued by the first party. To this 
end, the first party issues, by applying its secret key, a 
secret-key certificate on a public key of the second party. 

20 Not only can the second party verify the validity of the 

secret-key certificate issued by the first party, by using the 
public key of the first party, but, if the verification holds, 
it also is ensured that the secret-key certificate on the 
public key of the first party has been issued by the 

25 Certification Authority. In general, recursive application of 
secret-key certificates allows hierarchical certification 
trees to be formed that offer the same security as 
hierarchical certification trees formed from public-key 
certificates . 

30 An example of a secret-key certificate and a corresponding 
issuing protocol will now be described. As is common in the 
art, for any integer, /, the symbol Z/ denotes the set of 
integers {0,...,/-l}, for which addition and multiplication are 
defined modulo I. Let G q denote a group of prime order, q, for 

35 which no feasible algorithms are known to compute discrete 

logarithms, and let H be a one-way hash-function that maps its 
arguments to Z 2 . , where t is an appropriately large security 
parameter. The secret key of the Certification Authority is a 
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number x 0 in 7L q , and the corresponding public key is {g,h Q ), 
where h 0 denotes g xo , and both g and h 0 are in G q . The parties 
whose keys are to be certified use the same key set-up as the 
Certification Authority: the secret key of a party U is a 

5 number x in 2^, and the corresponding public key is h = g x . A 
secret-key certificate on h is a pair (c,r), where c is in Z 2 « 
and r is in G q , such that c is equal to H(h, g r (h 0 h)~ c , I) . Here, / 
is an, optionally included, string consisting of additional 
information about the party associated with the public key. 

10 As will be clear to those of ordinary skill in the art, the 
certificate of the Certification Authority in effect is a 
Schnorr signature (see; Schnorr, C, " Efficient Signature 
Generation by Smart Cards , " Journal of Cryptology, Vol. 4, 
No. 3, (1991), pp. 161-174) on g x , made with secret key 

15 i 0 + i mod g . Anyone can feasibly generate pairs /i,(c, r) such that 
the verification relation holds, by taking h equal to h^ 1 g s for 
an arbitrary s in Z g , and a equal to g t for an arbitrary t in 
Z 9 ; the pair (c, sc + t mod q) , with c = H{h, a, /) , then matches h. 
However, the ability to feasibly generate such pairs together 

20 with the secret key \og g h would enable one to forge Schnorr 
signatures . 

To issue a secret-key certificate, the Certification 
Authority can proceed as follows. It generates at random a 
number w in Z,, and computes a = g w . It then computes 

25 c = H(/i,a, /) and r = c(x 0 + x) + w mod q, and transfers (c,r) to W, As 
will be demonstrated in the detailed description, the issuing 
protocol can be modified such that the need for the 
Certification Authority to know the secret key of U can be 
prevented. Moreover, a variety of blinding capabilities for U 

30 can be incorporated into the issuing protocol . 

In sum, the present invention describes certificate 
techniques based on public-key cryptography, that solve 
problems related to the well-known cryptographic technique of 
public-key certificates. 

35 PgTAIUSD DESCRIPTION OF THE INVENTION 

While it is believed that the notation of FIGS. 2 to 12 
would be clear to those of ordinary skill in the art, it is 
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first reviewed here for def initeness . 

A variety of secret-key certificate issuing protocols is 
described by flowcharts. The actions performed by the parties 
participating in these protocols are grouped together into 
5 flowchart boxes. The party performing the actions described 
in a flowchart box is indicated by the column that the box is 
in. The columns are labeled by a symbol denoting the type of 
party. The term "party" is used to indicate an entity that 
might sometimes be regarded as an agent who performs a step or 
10 a collection of steps in a protocol. It might also be 

regarded as a means for performing those steps, and might be 
comprised of any suitable configuration of digital logic 
circuitry. For example, any box or collection of boxes from 
the figures could be realized by hard-wired and dedicated 
15 combinatorial logic, or by some sort of suitably programmed 

machine, a microprocessor for instance, such as are well-known 
in the art, just as long as it is able to perform the storage, 
input/output and transformational steps (possibly apart from 
the random source functions) described by the corresponding 
2 0 box or boxes. 

As is common in the art, for any integer, /, the symbol Z/ 
denotes the set of numbers {0,...,Z — 1} . Addition and 
multiplication of elements in Z| are defined modulo /. The 
symbol ZJ denotes the set of numbers in {0,...,/— 1} that are 
25 co-prime to /. Multiplication of elements in Z" is defined 

modulo I. As is well-known in the art, TL\ is called a ring of 
integers modulo Z, and Z* is called a multiplicative group of 
integers modulo / . 

The symbol w <— " denotes assignment, meaning that the 
30 variable or symbol on its left-hand side is assigned the value 
on its right-hand side to. The assignments do not necessarily 
imply that storage space must actually be reserved; they may 
indicate intermediate values manipulated in volatile memory. 
Another operation is a test for equality, indicated by the 
35 == symbol. As is common in the art, the protocol halts in case 
the equality does not hold. 

The symbol €^ indicates that the number, or each of the 
numbers, on its left-hand side is chosen from the set on its 
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right-hand side according to a uniform probability 
distribution, and independent of anything else. In practice, 
pseudo- random techniques may be used, and the deviation from 
the uniform distribution may be significant without resulting 
in an appreciable loss in security and/or privacy. Such 
techniques are well-known in the art. 

Another action is denoted by the word "Send, M followed by a 
colon and one or more numbers. This indicates that these 
numbers are sent by the party performing the actions described 
in the box to the other party participating in the protocol . 
The directed connections between the boxes indicate the order 
in which the actions that are grouped in the boxes are 
performed. 

Apparatus for Secret-Key Certificates Systems. 

15 A precise description of the apparatus for a secure secret-key 
certificate system will now be given. The apparatus comprises 
the following five means: 

1. First key generation means that, on being given as input 
at least a security parameter, outputs a secret key and a 

20 matching public key, to be used by the Certification Authority 
for certifying keys of parties that wish to participate in the 
cryptographic system. 

As will be clear to those of o rdinary skill in the art, the 
binary length of the output is polynomially (preferably 

25 linearly) related to the security parameter. 

The first key generation means is of a probabilistic nature, 
meaning that the key pair is generated in a substantially 
random manner. Preferably, the randomization process is based 
on the output of some physical source of randomness, possibly 

30 combined with the output of a cryptographically strong 

pseudo-random number generator by taking, for instance, the 
bitwise exclusive-or of the two outputs. 

2. Second key generation means that, on being given as 
input at least a security parameter, outputs a key pair 

35 consisting of a secret key and a matching public key, to be 
used by a party that wishes to participate in the 
cryptographic system. 
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As with the first key generation means, the output is the 
result of a suitable randomization process. The means may be 
operated by the party itself, by the Certification Authority, 
or by the both of them. The first and second key generation 
5 means may, but need not, be identical. 

3. Certificate verification means that, on being given as 
input the public key of the Certification Authority and a pair 
consisting of a public key and a presumed secret-key 
certificate, outputs a response that is to be interpreted as 

10 "yes " or "no . " 

Usually, the verification relation will be deterministic, 
but this need not be the case; the certificate verification 
means may be of probabilistic nature, performing a great many 
random trials in order to decide whether the presumed 

15 certificate is a secret-key certificate on the public key. 

The certificate verification means outputs n yes M if and only 
if the presumed certificate is a secret-key certificate on the 
public key. In other words, the certificate verification 
means defines what a secret-key certificate on a public key 

20 is. 

4. Certificate issuing means that, on being given as input 
the secret key of the Certification Authority and a pair 
consisting of a secret key and a matching public key of a 
party that requires a certificate, outputs a digital signature 
25 on the secret key, such that the certificate verification 
means, on being given as input the public key of the 
Certification Authority and a pair consisting of the public 
key and the issued digital signature, outputs "yes" (and so 
the output of the certificate issuing means is a secret-key 
30 certificate on the public key) . 

The certificate issuing means may, but need not, be of a 
probabilistic nature. 

Obviously, it will usually suffice to take only the secret 
key of the Certification Authority and the secret key of the 
35 party as input, since the public key can usually be computed 
from the secret key. 

As will be appreciated, the certificate issuing means can be 
such that the party, whose keys are to be certified, can keep 
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secret from the Certification Authority its secret key. In 
that case, the certificate issuing means itself comprises 
means controlled by the party, means controlled by the 
Certification Authority, and suitable interface means for 
5 allowing communication therebetween. The means controlled by 
the party takes as input the secret key of the party (and 
possibly also the public key of the party) , and the means 
controlled by the Certification Authority takes as input the 
secret key of the Certification Authority (and possibly also 
10 the public key of the party) . The final output is the result 
of processing by the means controlled by the party and the 
means controlled by the Certification Authority, where 
appropriate intermediate results may be communicated through 
the interface means. The precise actions to be performed by 
15 the means that the certificate issuing means comprises, must 
be described by a cryptographic protocol, henceforth called a 
secret-key certificate issuing protocol. 

Yet another variation is that the Certification Authority 
can compute the secret keys corresponding to any public key of 
20 a party that requires a secret-key certificate, because it 
knows additional trap-door information. 

These and other variations will be appreciated by studying 
the exemplary embodiments. For example, the certificate 
issuing process may be blinded by the means controlled by the 
25 party, according to a variety of criteria that will be 
described in the text . 

5. Certificate simulating means that, on being given as 
input the public key of the Certification Authority, outputs a 
pair consisting of a public key and a matching certificate. 
30 The public key that is output is such that it could have 

been output by the second key generation means (as part of the 
pair that it outputs) . "Matching" indicates that the 
certificate verification means, on being given as input the 
public key of the Certification Authority and the output of 
35 the certificate simulating means, outputs "yes." The 

certificate simulating means is of a probabilistic nature, and 
the probability distribution of its output should be 
substantially indistinguishable from the probability 
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distribution that applies when the public key is generated by 
the second key generation means and the certificate is 
generated by the certificate issuing means. 

As will be clear to those of ordinary skill in the art, 
5 "substantially" indistinguishable may mean "computationally, " 
"statistically, " or "perfectly" indistinguishable, each of 
which has a precise mathematical meaning that is well-known in 
the art. Obviously, the indistinguishability property need 
not be this strong for practical purposes. For instance, if 
10 the set of possible outputs produced by the certificate 
simulating means on being given a certain input is 
sufficiently large, it might still be infeasible in practice 
to distinguish between simulated pairs and "genuine" pairs 
consisting of a public key and a matching secret-key 
15 certificate. 

In applications in which parties wish to generate pairs 
consisting of a public key and a corresponding secret-key 
certificate, without cooperation of the Certification 
Authority, the certificate simulating means must obviously be 
20 constructed. However, as will be illustrated later on, the 
certificate simulating means need not always build. 

Each of the described five means can be realized by 
hard-wired and dedicated combinatorial logic, or by some sort 
of suitably programmed machine, a microprocessor for instance, 
25 such as are well-known in the art. 

A secret-key certificate on a public key, as issued by the 
certificate issuing means, is in effect a digital signature on 
the secret keys corresponding to the public key. Hence it is 
unfeasible for parties other than the Certification Authority 
30 to generate, without involvement of the Certification 

Authority, new triples consisting of a secret key, a matching 
public key (meaning that the pair could have been generated by 
the second key generation means) , and a corresponding 
secret-key certificate (meaning that the certificate 
35 verification means would output "yes" when being given as 

input the public key of the Certification Authority, and the 
public key and the certificate) . 

It is stressed that the secret-key certificate is said to be 
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a secret-key certificate on the public key, not on the secret 
key: both the certificate issuing means and the certificate 
simulating means can output pairs consisting of a public key 
and a secret-key certificate on the public key. This 
5 emphasizes that there is a publicly verifiable relation 
between the public key and the secret-key certificate. 

Turning now to FIG. 1, an exemplary description of the 
interconnection and cooperation of the constituent parts 
described above will now be presented. All the lines in FIG. 
10 1 imply the transfer of messages. These may be held initially 
or delayed on their way, encoded and decoded cryptographically 
or otherwise to provide their authenticity and/or secrecy 
and/or error detection and/or error recovery. Thus the 
particular means or methods whereby messages are transferred 
15 are not essential to the present invention, and it is 

anticipated that any technique may be employed in this regard. 
The lines may for example be taken to represent communication 
means, in which case they might be realized in a variety of 
exemplary ways including conductive paths, fibre optic links, 
20 infra-red transmission, or paths through a packet switched 
network; also suitable drivers, modems, or other appropriate 
interfaces may be required at the ends of such lines, as are 
well-known in the art. Alternatively, the lines may be taken 
to stand for a message transfer step. 
25 First key generation means 113 transforms a security 

parameter on line 102 to a key pair for the Certification 
Authority. The key pair consists of a public key, output on 
line 106, and a secret key, output on line 105. The 
transformation of key generation means 113 depends on, amongst 
30 others, random number generator 119. 

Second key generation means 112 transforms a security 
parameter on line 101 to a public key, output on line 103, and 
a secret key, output on line 104. The transformation of key 
generation means 112 from the security parameter on line 101 
35 to the keys on lines 103 and 104 depends on, amongst others, 
random number generator 118 . The outputs of the key 
generation means will be certified by certificate issuing 
means 114, as detailed next. 
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Certificate issuing means 114 takes three inputs, on lines 
103, 104, and 105. The input on line 103 is the public key 
output by key generation means 112, and the input on line 104 
is the secret key output by key generation means 112. The 
5 input on line 105 is the secret key of the Certification 
Authority output by key generation means 113. Certificate 
issuing means 114 transforms these three inputs to a 
secret-key certificate on the public key of line 103. This 
secret-key certificate is a digital signature on the secret 
10 key of line 104, and is output on line 107. Not displayed is 
an optional random generator in certificate issuing means 114, 
although the preferred embodiments that are described in 
detail use randomness in the certificate issuing means. 

The certificate, output on line 107, is fed into certificate 
15 verification means 116, together with the public key that was 
output by key generation means 112 on line 103. The public 
key of the Certification Authority on line 106 is also fed 
into certificate verification means 116. The certificate 
verification means outputs a binary value on line 110, which 
20 is to be interpreted as a verdict about the correctness of the 
inputs on lines 103 and 107. In the block diagram, the input 
on line 107 to certificate verification means 116 is the 
output of certificate issuing means 114, and the input on line 
103 is the same as the input to certificate issuing means 114. 
25 Hence, the verdict on line 110 will in this case be 

affirmative ("yes"). Not displayed is an optional random 
generator in certificate verification means 116. The 
preferred embodiments that are described in detail do not use 
randomness in the certificate verification means. It is 
30 conceivable that for certain applications it may be necessary 
to incorporate randomness in the certificate verification 
means . 

The public key of the Certification Authority on line 106 is 
fed into certificate simulating means 115. Depending on, 
35 amongst other, random number generator 120, the certificate 
simulating means 115 transforms the input on line 106 to a 
public key on line 109, and a secret key certificate on this 
public key on line 108. When the two outputs of certificate 
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simulating means 115, and the public key of the Certification 
Authority on line 106, are fed into certificate verification 
means 117, a binary value is output on line 111. This output 
is a verdict about the correctness of the inputs on lines 109 

5 and 108, and will in the displayed situation be affirmative 
("yes"). Certificate verification means 117 is the same as 
means 116, as are all its input and output lines, and has been 
drawn twice only to emphasize that the certificate 
verification means cannot distinguish between a secret-key 

10 certificate output by certificate issuing means 114, and a 
secret-key certificate that is output by certificate 
simulation means 115. 

A variety of exemplary secret-key certificate systems for 
each of two preferred embodiments will now be provided. The 

15 Certification Authority will henceforth be denoted by CA, and 
a party in the system by U (for "user") . In both preferred 
embodiments, the various secret-key certificates that will be 
described are constructed from a class of signature schemes 
that is well-known in the art, henceforth referred to as 

20 Fiat /Shamir type signatures, by applying an inventive general 
construction technique. (Fiat /Shamir type signature schemes 
are signature schemes that are derived from secure 
three-transmission identification schemes of the 
challenge-responses type, by taking the challenge as a one-way 

25 hash of at least the message and information provided by the 
prover in the first transmission. See, Fiat, A. and Shamir, 
A. , " How to prove yourself: practical solutions to 
identification and signature problems , " Crypto *86, 
Springer-Verlag (1987), pp. 186-194. References to 

30 Fiat/Shamir type signature schemes that are well-known in the 
art are provided at in the detailed description.) This 
inventive technique will now be described, and will henceforth 
be referred to as the "general construction technique . " 

General Construction Technique. 

35 A triple consisting of a secret key of U, a matching public 

key of U, and a secret-key certificate on the public key of U t 
is characterized by (1) the signature scheme that is used by 
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the CA and (2) the type of key pair of U that is certified. 
Denoting the public key of U by h, and that of the CA by h D , a 
secret-certificate on h, when constructed by applying the 
general construction technique to a Fiat /Shamir type signature 
5 scheme, is in effect a signature of this underlying 

Fiat/Shamir type on the message h, made with a secret key that 
corresponds," under the signature scheme used by the CA, to 
public key h 0 h. 

The general certificate simulation technique for the 
10 resulting secret-key certificates consist of generating h as 
h^ l h' 0 . such that one knows a secret key that corresponds to h' 0 
under the signature scheme used by the CA. This enables one 
to generate pairs consisting of a public-key and a secret-key 
certificate on the public key, without cooperation of the CA. 
15 As will be appreciated, the examples illustrate techniques 
and concepts of the present invention, but they are only 
intended to be suggestive and not limiting in any way. For 
example, other construction techniques than the one described 
in the preceding paragraphs, or variations thereof, may be 
20 used as well. An example of this will be provided at the end 
of the first preferred embodiment. 

FIRST PREFERRED EMBODIMENT 

In the first preferred embodiment computations are performed 
in a (multiplicatively written) group of prime order q, for 

25 which efficient algorithms are known to multiply, determine 
equality of elements, -test membership, and to randomly select 
elements. This group will henceforth be denoted by G, . No 
feasible methods should be known to compute discrete 
logarithms in G, . Various types of such groups are known. 

30 For example, one can take the unique subgroup of order q of 

Z*, where p is a prime number such that q is a divisor of p-1. 
Another example is an elliptic curve over a finite field. For 
this reason, no explicit choice for G, is made in the 
descriptions . 

35 An expression such as g x should be understood to be a 
computation in G, . In case computations modulo q are 
performed, (as, for example, in r 0 = c(z 0 + i) + w 0 mod q) . the 
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modulo operator will be denoted explicitly. In case an 
element is chosen from a group, it is implicitly assumed that 
it is the smallest positive representative. The same holds 
for outcomes of computations. 

5 1. First Exemplary Secret-Key Certificate. 

A first exemplary secret-key certificate in the first 
preferred embodiment, constructed by applying the general 
construction technique to the Schnorr signature scheme (See, 
Schnorr, C, , " Efficient Signature Generation by Smart Cards , w 

10 Journal of Cryptology, Vol. 4, No. 3 (1991), pp. 161-174), 
will now be described in detail. 

Key generation means of the KAC: The secret key of the CA is 
a number x 0 in Z 9 , and the corresponding public key is (<?, h 0 ) in 
G,xG 9 , where g is a generator of G q and h 0 denotes g Xo . 

15 Preferably, x 0 is chosen uniformly at random in Z 9 , and g is 
chosen uniformly at random in G q \{l}. 

The pair (g,h 0 ) and the description of G q are made publicly 
known by the CA. The CA also makes publicly known a 
hash- function H, which maps its arguments to, say, Z 2 « , for 

20 some appropriate security parameter t (as will be clear to 

those of ordinary skill in the art, instead of Z 2 t , any Z/ for 

sufficiently large / can be chosen this choice is merely for 

concreteness ) . This function should meet the requirements 
that are believed to make the Schnorr signature scheme secure. 

25 Preferably, H is collision-free: this means that it is 

unfeasible to compute two distinct arguments that are mapped 
by 7i to the same outcome. Functions that are believed to be 
collision-free are well-known to those of ordinary skill in 
the art. 

30 Certificate verification means: A secret-key certificate on 
a public key h in G q of U is a pair (c, r) in Z 2 * x Z 9 such that c 
is equal to W(h, g r (h 0 h)~ c , I) . Here, / is a string containing the 
name of U , and possibly additional information such as 
address, employer, electronic mail, and a list of access 

35 rights. The incorporation of / in the hash-value is not 
strictly necessary, but may be required in practice. 

The secret-key certificate can alternatively be taken to be 
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a pair (a,r) in G,xZ r In that case, the pair is a secret-key 
certificate on h if g r (h 0 h)~ c is equal to a, where c is computed 
as H{h,a,I). 

As will be clear to those of ordinary skill in the art, the 
5 secret-key certificate has been constructed from the Schnorr 
identification scheme by applying the general construction 
technique: the certificate is in effect a Schnorr signature 
on h made with secret key log g (h 0 h), corresponding to the 
public key h 0 h. 

10 Key generation means of U: In addition to the signature 

scheme employed by the CA, the type of key pair of U must be 
specified in order to define the secret-key certificate. In a 
general form, the secret key of U can be taken to be a tuple 
(xi, . . . ,x fc )# such that each x { is in Z 9 , and h is equal to n*=i 9V • 
15 Here, g u ... y g k are randomly chosen generators of G q (they need 
not all be different from g) , that are published by the CA in 
addition to j, h 0 , and the descriptions of G q and H, 

For each g { {1 < i < k) , the CA should preferably know log g g x 
(in order to be able to conduct the issuing protocol) . 
20 Hereto, the CA may generate as follows: it generates 

at random 3/1,... ,2/* in Z 9 , and sets p, equal to g Vi . (The CA can 
take one of the numbers g> equal to g; as will be demonstrated 
by the flowchart of FIG. 6, such a choice allows restrictive 
blinding of the issuing protocol. As will be obvious to those 
25 of ordinary skill in the art, instead of taking one of the g x ' s 
equal to g, the same effect is obtained by taking this p t equal 
to a publicly known power of g.) Observe that the secret key 
that corresponds to the public key h 0 h, in the signature 
scheme employed by the CA, is the number log 9 (/i 0 ^)/ which is 
30 equal to x 0 + £*=i ViX* mod q ; if the described generation process 
for ffi,...,9*r is used, then the CA can compute this number. 

In practice, one may want to use a simpler form of key pair. 
The simplest form is one in which the secret key of U is a 
number x in G q , and the public key h is equal to g x (that is, 
3 5 there is only one g it and it has been taken equal to y). This 
enables U to perform such cryptographic tasks as computing 
Schnorr signatures and proving knowledge of his secret key 
(three detailed examples will be provided below) . Another 
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simple form is one in which the secret key of U is a pair 
(x x ,x 2 )* such that h is equal to g\ x gl 2 . Here, as mentioned, one 
of pi or g 2 may be taken equal to j (or both, but then there is 
no advantage in this form over the more efficient form where h 
5 is equal to g x ) . This form also enables U to perform 

cryptographic tasks such as computing signatures and proving 
knowledge of his secret key. As will be demonstrated in the 
flowchart of FIG. 6, this second form is of particular 
importance for the construction of restrictive blind signature 

10 protocols, in that for such a protocol it is required that <h 
is taken equal to j (or a publicly known power of g) , and U 
should not be able to compute log 9 <? 2 or log^e^- 

Certificate simulating means: Anyone can feasibly generate 
pairs /i, (c, r) such that the verification relation holds, by 

15 taking h equal to h$ x g* for an arbitrary s in Z 9 , and a equal 
to g l for an arbitrary t in Z 9 ; the pair (c, 5C + 1 mod g) , with c 
equal to H(/i,a, /), then is a secret-key certificate on h. 
However, the ability to feasibly generate such pairs together 
with a secret key, that corresponds to the public key h 

20 according to one of the key generation schemes for U described 
in the preceding three paragraphs, enables one to forge 
Schnorr signatures . 

A complete secret-key certificate system also requires the 
description of a certificate issuing protocol, in addition to 

25 the description of the secret key certificate itself. A 
variety of exemplary protocols for issuing the described 
secret-key certificate can be constructed. Each such 
certificate issuing protocol can be characterized by the 
degree by which U , to whom the certificate is issued by the 

30 CA, can "randomize" and "blind" the secret key, the public 
key, and the secret-key certificate. Before providing 
exemplary embodiments for various certificate issuing 
protocols, though, a few examples are provided that will help 
those of ordinary skill in the art to appreciate how the 

35 described secret-key certificate may be used in practice. 

1.1. Examples for the first exemplary secret-key certificate. 
Without loss of generality, it will be assumed in the examples 
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that a public-key directory is used. (Alternatively, the 
public keys and secret-key certificates on the public keys may 
be sent on request.) The entries in the public-key directory 
will be of the following form: 





User 


(Public key, Certificate) 




h 


^1/ (Cl)*"l) 


5 




h 2 , (c 2 ,r 2 ) 




h 


hk* (cjfc,r fc ) 



By virtue of the simulatability of secret-key certificates, 
any one of the entries could have been generated without 
cooperation of the CA. 

As will be clear to those of ordinary skill in the art, the 

10 numbers h in the entries of the public-key directory need not 
refer to the identity of the party associated with the entry: 
instead, they may refer to a pseudonym of the party, and the 
party may have a plurality of such pseudonyms. 

For simplicity, in each of the examples it will be assumed 

15 that the key pair of U is of the simplest form; the secret key 
is a number x in Z 9 , and the corresponding public key h is 
equal to g x . As will be clear to those of ordinary skill in 
the art, similar examples can be provided when U uses a 
different type of key pair. In particular, many techniques 

20 and examples in which the more general form of key pair for U 
is used, are described and claimed in patent application Ser . 
No. PCT/NL.94/00179 . 

Example 1 : Suppose that user U 1 wants to transfer an 
encrypted message m in G q to U 2 (by electronic facsimile, 

25 electronic mail, or any other suitable medium) . The 

encryption scheme which is used is the ElGamal scheme (See, 
ElGamal, T. , " A public key cryptosystem and a signature scheme 
based on discrete logarithms , " IEEE Transactions on 
Information Theory, Vol. IT-31, No. 4, July 1985, pp. 

30 469--472) in the group G q . From the public-key directory, U 1 
retrieves the public key h 2 of U 2 , and the string (c 2 ,r 2 ). If c 2 
is equal to 7i(h 2 , g T7 (h 0 h 2 )' C2 , 1 2 ) , then U l can safely transfer the 
encrypted message to U 2 . Hereto, he generates at random a 
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number s in Z 9 , and transfers the pair {g-.h^vn) to U 2 . If 2 
can decrypt and retrieve m, then he must know log p h 2 (as will 
be clear to those of ordinary skill in the art, this holds 
under the Dif f ie-Hellman key exchange assumption in G q , and 
5 for randomly chosen m) . This in turn implies that he could 
not have generated (/i 2 , (c 2 , r 2 )) by himself. In other words, U 1 
can rest assured that IA 2 can recover m if and only if the key 
pair of U 2 has been certified by the CA. Of course, in 
practice bidirectional communication between Ui and U 2 will 
10 readily reveal to both parties whether the keys of the other 
party have been certified by the CA. 

Example 2 : Suppose that U 2 digitally signs a message m for 
U lt using the Schnorr signature scheme (alternatively, the 
ElGamal signature scheme can be used) . TA^ receives from U 2 a 
15 pair (c, r) such that c is equal to H(rn,g r h 2 c ) - If the public key 
h 2 of U 2 is listed in the public-key directory together with a 
pair (c 2j r 2 ) for which c 2 is equal to H(h 2 , g T2 {h 0 h 2 )~ C7 ,/ 2 ) , then the 
fact that U 2 can compute this signature also informs U 1 that 
the key pair of U 2 has been certified by the CA (unless the 
20 Schnorr signature scheme can be broken, but in that case the 
signature scheme of the users itself is also insecure) . As 
will be appreciated, this fact can be verified by anyone and 
so has legal significance, as it is unfeasible to forge a 
triple consisting of (1) a pair consisting of a public key and 
25 a secret-key certificate on the public key, (2) a message, and 
(3) a digital signature on the message made with the secret 
key corresponding to the forged certified public key. 

Example 3 : Suppose that U 2 wants to prove to Wi that his 
entry in the public-key directory has been certified by the 
30 CA, without leaving U x with a transcript of the proof that can 
be used to transfer the conviction to others. U 2 hereto 
proves knowledge of the secret key ~Loq g h 2 to Ui in a 
zero-knowledge protocol, which can be done, for example, as 
follows. U 2 transfers a number a in G q to U x , where a is 
35 equal to g w for a randomly chosen w in Z r U x responds with 
challenge c randomly chosen from a predetermined small range, 
say {0,1}, and transfers it to U 2 . U 2 must respond with 
c log y h 2 + w mod q, denoted by r for further reference . The 



BNSDOCID:<WO 9612362A2> 



WO 96/12362 



PCT/NL95/00350 



27 



10 



correctness of the response can be verified by U x by verifying 
whether g T h^ c is equal to a. This three-move interaction is 
repeated a substantial number of times, and if U 2 can always 
respond correctly then he must know log,/i 2 , thereby proving 
that the entry in the directory has been certified by the CA. 
As is well-known in the art, this is a zero -knowledge 
protocol. The conviction of U x cannot be transferred: 
transcripts of executions of this protocol are feasible to 
generate together with entries in the public -key directory, 
with indistinguishable probability distribution. 

1.2. First exemplary certificate issuing protocol. 

Certificate issuing means: Various certificate issuing 
protocols for issuing the described secret-key certificate 
will now be described. As before, for explicitness it will be 
15 assumed in each of these protocols that the key pair of U is 
of the simplest form; the secret key of U is a number x in Z, , 
and the corresponding public key h is equal to g x . Those of 
ordinary skill are believed to be able to straightforwardly 
apply the inventive techniques to suit the other types of key 
20 pairs for U , described previously. 

Recall that the secret-key certificate that will be issued 
to U by the CA is a pair (c,r) in Z 2 . x Z, such that c is equal 
to H(h,g r (h 0 h)- e ,I), where h is the public key of U. 

Turning now to FIG. 2, a flowchart of a first secret-key 
25 certificate issuing protocol in the first preferred embodiment 
will now be described in detail. 

Box 21 first shows the CA generating a secret key x in Z, 
for use by As indicated in the second line, the 

corresponding public key h of U is taken equal to g x . It will 
be clear to those of ordinary skill in the art that x may 
alternatively be generated by U and then communicated to the 
CA, or U and the CA can generate it together, for example in 
such a manner that x is mutually random. 

Box 22 first shows the CA generating at random a number w 
in Z, . The second line shows the CA computing g w , which is 
denoted by a for further reference. The third and fourth 
lines show the CA computing H(h,a,I), which is denoted by c. 



30 
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and c(x 0 + x) + w mod q , which is denoted by r. The CA then 
transfers the secret key x and the pair (c, r) to W ( as 
described by the fifth line. 

Box 23 first shows U computing his public key h, by setting 
5 it equal to g x . The second line indicates that U verifies if 
c is equal to the hash-value of the triple (/i, g r {h 0 h)~ c , I) . 

Clearly, if the equality holds then the pair (c, r) is a 
secret-key certificate on the public key h of U , such that U 
knows the secret key corresponding to h. 

10 1.3. Second exemplary certificate issuing protocol. 

In the certificate issuing protocol of FIG. 2, the CA must 
know the secret key of U . 

Turning now to FIG. 3, a flowchart of a secret-key issuing 
protocol that hides the secret key of U from the CA, in the 
15 first preferred embodiment, will now be described in detail. 

Box 31 first shows U generating at random a number x in Z g ; 
this will be his secret key. The second line shows U 
computing the corresponding public key h by setting it equal 
to j*. U then transfers h to the CA, as indicated by the 
20 third line. 

Box 32 first shows the CA generating at random a number w 
in Z 9 . The second line shows the CA computing g w , which is 
denoted by a for further reference. The third and fourth 
lines show the CA computing H{h,a,I), which is denoted by c, 
2 5 and cio + wmodg, which is denoted by r 0 - The fifth line 
indicates that the CA transfers the pair (c,r 0 ) to U . 

Box 33 first shows U verifying whether c is equal to the 
hash-value of the triple {Kg rt hZ c J) . As described by the 
second line, if this is the case then U computes r 0 + cxmodg, 
30 which is denoted by r. 

As can easily be verified by those of ordinary skill in the 
art, the pair (c, r) is "a secret-key certificate on the public 
key h, such that U knows the secret key corresponding to h. 

In this exemplary protocol, the secret key x can be freely 
35 chosen by W. It will be clear to those of ordinary skill in 
the art that the CA can randomize the secret key of U , for 
instance by using hg*' instead of h in Box 32. Here, x 9 is 
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randomly chosen by the CA from Z„, and made known to U only 
after the CA has received h (in addition, the CA can be 
requested to transfer a commit on x' to U before U reveals h) . 
In that case, the secret key of U is equal to x 4- x' mod q . 

5 1.4, Third exemplary certificate issuing protocol. 

Since there exist many secret-key certificates (c, r) on the 
same public key, the CA may choose a particular one and encode 
information in it that can be decrypted by insiders. 

Turning now to FIG. 4, a flowchart of a secret-key issuing 
10 protocol that hides the secret key from the CA and prevents 
the subliminal channel, in the first preferred embodiment, 
will now be described in detail. 

Box 41 first shows the CA generating at random a number w 0 
in Z g . The second line shows the CA computing g Wo , which is 
15 denoted by a 0 for further reference. The third line indicates 
that the CA then transfers a 0 to U . 

Box 42 first shows U generating at random a number x in Z 9 ; 
this will be his secret key. The second line shows U 
computing the corresponding public key h by setting it equal 
20 to g x . The third line shows U generating at random a number w 
in Z g , and the fourth line shows U computing g w , which is 
denoted by a. Finally, as described in the fifth line, U 
transfers the pair (/i, a) to the CA. 

Box 43 first shows the CA computing H(h, a 0 a, /) , which is 
25 denoted by c for further reference. The second line shows the 
CA computing cx 0 + u>o mo.d q , which is denoted by r 0 - As described 
by the third line, the CA then transfers r 0 to U . 

Box 44 first shows U computing c as did the CA in the first 
line of Box 43. The second line indicates that 14 verifies 
30 whether aa 0 is equal to g T *K c . As the third line displays, if 
this is the case then U computes r 0 4- cx -4- w mod q , which is 
denoted by r . 

As can easily be verified by those of ordinary skill in the 
art, the pair (c, r) is a randomized secret-key certificate on 
35 the public key h (meaning that the CA could not have encoded 
any information in it), such that U knows the secret key 
corresponding to h. 
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It will be obvious to those of ordinary skill that U in Box 
42 could transfer w to the CA, instead of a. In Box 43 the CA 
can then compute cx 0 + Wo + w 9 itself, to which U now must 
add only cx modulo g. 

5 1.5. Fourth exemplary certificate issuing protocol. 

In the issuing protocols described thus far, the CA knows the 
public key of U . For ordinary public-key directory 
applications, this is usually by definition the case, since 
anyone in such applications should be able to associate the 

10 public key with U . 

In cryptographic mechanisms for transfer of credentials, 
however, no public-key directories are used; the information 
representing a credential is only shown by the owner of the 
credential if he wants to demonstrate possession of his 

15 credential to a recipient. A commonly used mechanism is one 
in which a public key and a public-key certificate on the 
public key are transferred; the secret key of U corresponding 
to his public key enables U to do additional things such as 
sign the transfer, or prove possession of additional 

20 information (in on-line mechanisms U might do without needing 
to know a secret key, and the public key can be a message or a 
one-way hash thereof) . The credential is issued by the CA, 
and the type of credential that is issued can for instance be 
denoted by the type of signature that the CA computes. The 

25 certificate of the CA proves the validity of the credential to 
the recipient, and a signature made by U with his secret key 
proves that U willingly transferred the credential to the 
recipient. If the transfer mechanism is to be 

privacy-protected, then the CA should not know what the public 
30 key and the certificate are, because these are revealed when 
transferred. 

Turning now to FIG. '5, a flowchart of a fully blinded 
secret-key issuing protocol in the second preferred embodiment 
will now be described in detail. 
35 Contrary to the flowcharts of the preceding figures the 

string / should obviously not be hashed along with h and a if 
it reveals identifying information about U , such as his name; 
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otherwise, there would be no point in blinding the certificate 
issuing protocol. Although the CA may require U to hash along 
a string / that, for instance, indicates another party that U 
wishes to transfer the received information to, for 
5 convenience the string / will henceforth be omitted. 

Box 51 first shows the CA generating at random a number w 0 
in Z 9 . The second line shows the CA computing g wc , which is 
denoted by a 0 for further reference. As described by the 
third line, the CA then transfers a 0 to W. 
10 Box 52 first shows U generating at random a number x in ; 
this will be his secret key. The second line shows U 
computing the corresponding public key h, by setting it equal 
to g x . The third line shows U generating at random two 
numbers t,u in 7L q . Using these random numbers, the fourth line 
15 shows how U blinds a 0 , by computing a 0 g l h%; this number is 

denoted by a for further reference. The fifth line shows U 
computing H(h,a), which is denoted by c, and blinding it, as 
described by the sixth line, to c -hit mod q; this number is 
denoted by c 0 for further reference. As described by the 
20 seventh line, U then transfers c 0 to the CA. 

Box 53 first shows the CA computing c o x 0 + w 0 mod q , which is 
denoted by r 0 for further reference . As described by the 
second line, the CA then transfers r 0 to W. 

Box 54 first shows U verifying whether g r °ho c ° is equal to a 0 . 
25 As described by the second line, if this is the case then U 
computes r 0 + cx + t mod q, which is denoted by r. 

1.6. Fifth exemplary certificate issuing protocol. 

The certificate issuing protocols that have been described 
thus far in effect demonstrate techniques to incorporate 

30 various degrees of randomization that can be applied by U . 

A particularly valuable randomization is that in which U 
can perfectly blind the public key and the secret-key 
certificate on the public key, such that the CA gets no 
information about the pair, but cannot fully blind the secret 

35 key corresponding to the public key; more specifically, the 
secret key of U is a vector of at least two numbers, and U 
will not be able to blind a pre-determined non-constant 
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function of the numbers in the vector. Such an issuing 
protocol is a restrictive blind signature protocol, as 
described and claimed in patent application Ser. No. 
PCT/NL94/00179 . 

5 The benefit is of this technique is that, while U can show 

a credential (obtained by retrieving a secret key, a matching 
public key, and a secret-key certificate on the public key, by 
performing a restrictive blind signature protocol) without 
enabling traceability by the CA (because the public key and 
10 the certificate are fully blinded) , appropriate showing 

protocols (which require U to perform additional actions with 
his secret key) can limit the scope of the actions that U can 
perform. In patent application Ser. No. PCT/NL94/ 00179 , a 
wide variety of techniques for transferring credentials, 
15 obtained by performing a restrictive blind issuing protocol, 
are described and claimed. 

Turning now to FIG. 6, a first flowchart of a restrictive 
blind secret-key certificate issuing protocol for the first 
preferred embodiment will now be described in detail. This 
20 protocol is also described and claimed in patent application 
Ser. No. PCT/NL94/00179 , and, as will be appreciated, is 
included here (using the present notation) to clearly 
demonstrate that the protocol is a restrictive blind 
secret-key certificate issuing protocol. 
25 The key pair of U must be different from that used until 
now, because the secret key must be a vector of at least two 
numbers. For concreteness , the following choice is made: the 
secret key of U is a pair (x, 7) in Z 9 xZ, such that g x g[ is 
equal to h. Here, the CA has generated g 1 by generating at 
30 random a (secret) number j in Z, ( and setting p x equal to g y . 
As will be clear to those of ordinary skill in the art, this 
implies that it is unfeasible for parties other than the CA to 
compute log,£i. 

The second number of this pair, I , will be encoded by the CA 
35 into the secret key of U during the certificate issuing 

protocol. Although U is unable to modify 7, he will be able 
to generate x by himself uniformly at random in Z 9 . Hence, in 
effect h is generated at random in G qt independently from I. 
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As described before, the number / may be related to the 
identity of U , but can also contain unrelated information such 
as a credential specification. 

Box 61 first shows the CA generating at random a number w 0 
5 in Z 9 . The second line shows the CA computing g™ 0 , which is 
denoted by a Q for further reference. As described by the 
third line, the CA then transfers a 0 to U . 

Box 62 first shows U generating a number x in Z 9 ; the pair 
(x,I) will be his secret key. The second line shows U 
10 computing the corresponding public key h, by setting it equal 
to g x g[. In addition, as displayed in the third line, U 
generates two random numbers £,u in Z 9 , which will serve to 
obtain blinded r and c. The fourth line shows U computing 
a 0 g t (h 0 g[) u , which is denoted by a for further reference. As 
15 indicated in the fifth line, U then computes H(h,a), which is 
denoted by c. The sixth line specifies U computing c + umodg, 
which is denoted by c 0 . As described by the seventh line, U 
then transfers c 0 to the CA. 

Box 63 first shows the CA computing c 0 (x 0 + yl) + w 0 mod q , which 
20 is denoted by r 0 for further reference. As described by the 
second line, the CA then transfers r 0 to W. 

Box 64 first shows U verifying whether g r *(h 0 g[)~ Co is equal to 
a Q . As described by the second line, if this is the case then 
U computes r 0 +ci + fmodg, which is denoted by r. 
25 As can easily be verified by those of ordinary skill in the 
art, the pair (c, r) is a secret-key certificate on the public 
key h of U , such that U knows a secret key corresponding to h. 
Although U has perfectly blinded h and (c,r), it is unfeasible 
for him to completely blind the secret key. That is, the 
30 secret key of U is a pair (i,/') such that g x g{' is equal to h, 
and if (c, r) is to be a secret-key certificate on h then /' is 
equal modulo q to the number / that the CA in Box 63 encoded 
into its response r. 

1.7. More than one receiving party. 

35 As will be appreciated, the protocol displayed in FIG. 6 can 
also be used by the CA to issue the secret-key certificate to 
U and an additional party T that is substantially under 
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control of the CA, such that: U will get to know the public 
key and the secret-key certificate on the public key; and the 
secret key corresponding to the public key is shared between U 
and T in such a way that neither of U and T can determine it. 
5 To this end, the CA initially makes / known to X but not to U : 
the CA only informs U of g[ . The protocol displayed in FIG. 6 
remains exactly the same, but now U in a succeedirg 
certificate showing protocol can only compute signatures, or 
prove knowledge of the secret key, when T cooperates: T 

10 knows J, and U knows rr, and the certified public key is equal 
to g x g[ . As will be appreciated, T does not need to 
participate in the secret-key certificate issuing protocol due 
to the initial set-up in which the CA only makes / known to T. 
In patent application Ser. No. PCT/NL94/00179 , techniques are 

15 detailed and claimed for T and U to conduct a succeeding 
certificate showing protocol such that: J can be computed 
when T and U perform the showing protocol at least twice in 
response to different challenges; or / can never be computed, 
no matter how often U and T perform the showing protocol. 

20 Other variations of the issuing protocol, for the case the 
certificate is issued to U and T in the manner described in 
the preceding paragraph, will be obvious to those of ordinary 
skill in the art. One such variation is that g 1 is taken 
equal to g in FIG. 6 (and correspondingly y equals 1) : in 

25 that case, T at the end of the issuing protocol knows /, and U 
knows x, and the certified public key is equal to g x + ! . As 
will be appreciated, the resulting issuing protocol in effect 
is that described by FIG. 5, where the role of the CA is now 
played by the CA and T together. Instead of using secret key 

30 x 0 , their secret key now is equal to i 0 + / mod g . 

2. Second Exemplary Secret-Key Certificate. 

Each of the exemplary flowcharts that has been described thus 
far demonstrates a specific type of issuing protocol. The 
secret-key certificate that is issued is the same in all the 
35 flowcharts . 

As described earlier, the general construction technique can 
be applied to any other signature scheme of the Fiat/Shamir 
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type as well. Although it is believed that the detailed 
descriptions provided thus far will enable those of ordinary 
skill in the art to straightforwardly apply the general 
construction technique to other Fiat /Shamir type signatures, 
5 the general construction technique will now be applied to 
several other Fiat /Shamir type signatures for illustrative 
purposes. No issuing protocols will be described for these 
certificates, since it is believed to be an easy matter for 
those of ordinary skill in the art to apply the inventive 
10 techniques of FIGS. 2 to 6 to suit the new certificates 

(except for one particular certificate, that does not seem to 
allow blinded issuing; this will be indicated in the 
description of that particular certificate) . 

A second exemplary secret-key certificate in the first 
15 preferred embodiment, constructed by applying the general 

construction technique to the Okamoto signature scheme (See, 
Okamoto, T., Section 6.1. in " Provably Secure and Practical 
Identification Schemes and Corresponding Signature Schemes , " 
Crypto '92, Lecture Notes in Computer Science 740, 
20 Springer-Verlag (1993), pp. 31-- 53), will now be described. 

Key generation means of the KAC : The secret key of the CA is 
a pair (xi,x 2 ) in Z,xZ, ; and the corresponding public key is 
(Si,S2,^o) in G q xG q , where g x and g 2 are generators of G qt and h 0 
denotes gt^gV • Preferably, x l and x 2 are chosen uniformly at 
25 random in Z^, and g 1 and g 2 are chosen uniformly at random from 
G 9 \{1}. 

The tuple (91,32,^0) and the description of G q are made 
publicly known by the CA. The CA also makes publicly known a 
hash-function H, which maps its arguments to, say, Z 2 « , for 
30 some appropriate security parameter t. This function should 
meet the requirements that are believed to make the Okamoto 
signature scheme secure. Preferably, H is collision-f ree . 

Certificate verification means: A secret-key certificate on 
a public key h in G q of U is a triple (c,r ll r 2 ) in Z 2 . x 2, x Z, 
35 such that c is equal to H{h, gl 1 g r 2 2 (h 0 h)' c , I) . 

Alternatively, the secret-key certificate can be taken to be 
a triple (a,r 1) r 2 ) in G 9 xZ ? xZ r In that case, the triple is a 
secret-key certificate on h if gl l g?(^ 0 h)' c is equal to a, where 



WO 96/12362 PCT/NL95/00350 

t\ * 

36 

c is computed as 7i{h,a,I) . 

The certificate is in effect an Okamoto signature on h made 
with a secret key that corresponds to the public key h 0 h. 
Key generation means of U: The discussion of key pairs 

5 provided earlier with respect to the first secret-key 

certificate for the first preferred embodiment, applies here 
as well. (As will be clear to those of ordinary skill in the 
art, the symbols <h,S2* ^1^2 chosen here for convenience, do 
not refer to the symbols in that discussion. ) 

10 Certificate issuing means: Those of ordinary skill in the 
art are believed to be capable of straightforwardly applying 
the inventive techniques for (a) the issuing protocols of 
FIGS. 2 to 6, and (b) the inventive technique to issue the 
secret-key certificate to U and an additional party T, to 

15 construct similar certificate issuing protocols for the 
present secret-key certificate. 

3. Third Exemplary Secret-Key Certificate. 

A third exemplary secret-key certificate in the first 
preferred embodiment, constructed by applying the general 

20 construction technique to the Brickell/McCurley signature 
scheme (See, Brickell, E. and McCurley, K. , 
" An interactive identification scheme based on discrete 
logarithms and factoring , " Journal of Cryptology, Vol. 5, no. 
1 (1992), pp. 29-39), will now be described. 

25 As is well-known in the art, the Brickell/McCurley technique 
can be applied to both the Schnorr and the Okamoto signature 
scheme. This technique consists of making sure that the order 
q of the group G g remains unknowvi to U; instead, computations 
that are performed modulo q in the Schnorr or Okamoto scheme 

30 are replaced by computations of a large multiple of 9. To 

this end, it will be assumed in the description that G q is the 
unique subgroup of order q of Z*, where, p is a prime such 
that q divides p— 1, and p — 1 also contains another prime 
factor of size comparable to the size of q (such as to prevent 

35 efficient factorization of p— 1) . Only the CA may know q, to 
speed up computations for its internal use. For explicitness , 
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the application to the Schnorr signature scheme will be 
assumed. 

Key generation means of the KAC : This is the same as for the 
first secret-key certificate, only this time G q is of the 
5 specific form described above, and q is not made publicly 
known. In case not even the CA knows q, x 0 is chosen at 
random from Z p _! . 

Certificate verification means: A secret-key certificate on 
a public key h in G q of U is a pair (c, r) in Z 2 < x Z p _i such that 
10 c is equal to H(h, g r (h 0 h)~ c , I) . 

As with the first secret-key certificate, alternatively a 
pair (a,r) in G q x Z p _! can be taken to be the certificate. 

Key generation means of U : The discussion of key pairs 
provided earlier with respect to the first secret-key 
15 certificate for the first preferred embodiment, applies here 
as well, with the difference that the secret key (or: each of 
the numbers in the secret key, for the general form) of U is 
chosen in Zp_! . 

Certificate issuing means: Again, it is an easy matter to 
20 apply the inventive techniques for (a) the issuing protocols 
of FIGS. 2 to 6, and (b) the inventive technique to issue the 
secret-key certificate to U and an additional party T, to 
construct similar certificate issuing protocols for the 
present secret-key certificate. Hereto, all operations that 
25 are performed modulo q must be replaced by operations modulo 

p-1 (if the CA knows q, it can of course still compute g w , for 
w in Zp_i, by computing g"****) . 

4. Fourth Exemplary Secret-Key Certificate. 

A fourth exemplary secret-key certificate in the first 
30 preferred embodiment, constructed by applying the general 

construction technique to the DSA (See, NIST, " Specifications 
for a digital signature standard (DSS) , " Federal Information 
Processing Standards Pub. (draft), Aug. 19, 1991), will now be 
described. 

35 Key generation means of the KAC : The secret key of the CA is 
a number x 0 in Z 9 , and the corresponding public key is (g, h 0 ) in 
G q xG qt where g is a generator of G q and h 0 denotes g*° . 
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The pair (g, h 0 ) and the description of G q are made publicly 
known by the CA. The CA also makes publicly known a 
hash-function W, which maps its arguments to, say, Z 2 * , for 
some appropriate security parameter t. This function should 
5 meet the requirements that are believed to make the DSA 
secure . 

Certificate verification means: A secret-key certificate on 
a public key h in G q of U is a pair (a,r) in Z 9 x TL q such that 
((0 cr ~ 1 (/i o /t) ar ~ 1 ) mod q) is equal to a, where c denotes K(h,I). 
io Key generation means of U : The discussion of key pairs 
provided earlier with respect to the first secret-key 
certificate for the first preferred embodiment, applies here 
as well. 

Certificate issuing means : Those of ordinary skill in the 
15 art are believed to be capable of straightforwardly modifying 
the issuing protocol of FIG. 2 to construct a similar 
certificate issuing protocol for the present secret-key 
certificate. It is important to note that for this particular 
realization, contrary to the other secret-key certificates 
20 systems described in this application, it is unclear how to 
construct issuing protocols similar to the issuing protocols 
of FIGS. 3 to 6. 

5. Fifth Exemplary Secret-Key Certificate. 

It will now be demonstrated that certain variations of the 
25 general construction technique can be used as well. A fifth 

exemplary secret-key certificate in the first preferred 

embodiment, constructed by applying a variation of the general 

construction technique to the Schnorr signature scheme, will 

now be described in detail. 
30 Key generation means of the KAC : This is the same as in the 

description of the first secret-key certificate. 

Certificate verification means: A secret-key certificate on 

a public key h in G q of U will now be taken to be a pair (c, r) 

in Z 2 < x Z 9 such that c is equal to H{h, g r h~ c , I) . 
35 The secret-key certificate can alternatively be taken to be 

a pair (a,r) in G g xZ 9 such that g r h' c is equal to a, where c is 

computed as 7i(k, a, /) . 
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It seems that this secret-key certificate has not been 
constructed from the Schnorr identification scheme by applying 
the general construction technique: the public key h 0 seems 
to have "disappeared" from the verification relation. 
5 However, it now has to show up in the definition of the type 
of key pair used by W. In other words, merely a slight 
variation of' the general construction technique has been 
applied. 

Key generation means of U : In general, for the modified 
10 secret-key certificate to be secure, the public key of U must 
be defined as a product g{ 1 • gl k /io* +l , where none of the 
randomly chosen elements g { is equal to j (or a publicly known 
power thereof) . As with the first secret-key certificate, 
0ii---»fffc are randomly chosen generators of G q that are 
15 published by the CA in addition to g, h 0t and the descriptions 
of G q and H. 

In practice, one may want to use a simpler form of key pair. 
The simplest form is one in which the secret key of U is a 
number x in G qt and the public key h is equal to (h 0 ) T , and h 
20 may not be equal to 1. Another simple form is one in which 
the secret key of U is a pair (z li x 2 ), such that h is equal to 

To demonstrate that all the issuing techniques provided for 
the first secret-key certificate in the first preferred 

25 embodiment can be straightforward applied to construct issuing 
protocols for the modified secret-key certificate, the most 
difficult to realize type of issuing protocol for the modified 
secret-key certificate will now be described. 

Turning now to FIG. 7, a second flowchart of a restrictive 

30 blinded secret-key certificate issuing protocol for the first 
preferred embodiment will now be described in detail. 

The secret key of U is a pair {x,I) in Z,xZ 9 , and the public 
key h is equal to gfh J 0 . As in the previous flowchart, the CA 
has generated g 1 by generating at random a (secret) number y in 

35 Z 9 , and setting g x equal to g v . The blinding that can be 
performed by U in the protocol differs from that in the 
preceding protocol, but the restrictivi ty property still 
holds: the number that the CA will encode into the secret key 
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(x y I) of U is equal to J/xmodg. 

As in the preceding flowchart, at the start of the issuing 
protocol the CA decides on a number / in 7L q that will be 
encoded into the secret key of U when the issuing protocol is 
5 performed. 

Box 71 first shows the CA generating at random a number w 0 
in Z 9 . The second line shows the CA computing g™ 0 , which is 
denoted by a 0 for further reference. As described by the 
third line, it then transfers a 0 to U, 

10 Box 72 first shows U generating a number x in Z 9 ; the pair 
(i, /i mod ?) will be his secret key. The second line shows U 
computing the corresponding public key h, by setting it equal 
to (h 0 g{) x . In addition, as specified by the third line, U 
generates two random numbers t,u in Z g , which will serve to 

15 obtain blinded r and c. The fourth line shows U computing 
fco^H^oPi) 3 " 1 ' which is denoted by a. The fifth line shows U 
computing a), which is denoted by c. The sixth line shows 

U computing c 4- ti mod g , which is denoted by c 0 . As described by 
the seventh line, U then transfers c 0 to the CA. 

20 Box 73 first shows the CA computing c 0 (x 0 + yl) + w 0 mod g, which 
is denoted by r 0 for further reference. As described by the 
second line, the CA then transfers r 0 to W, 

Box 74 first shows U verifying whether <7 r °(/io<?D~ c ° ^ s equal to 
a 0 . As described by the second line, if this is the case then 

25 U computes r 0 x -f fmodg, which is denoted by r . 

As can easily be verified by those of ordinary skill in the 
art, the pair (c, r) is a secret-key certificate on the public 
key h of U, such that U knows a secret key corresponding to h. 
The following holds: the secret Key of U is a pair such 

30 that hlg{' is equal to h, and if (c, r) is to be a secret-key 

certificate on h then I'/xmodq is equal modulo q to the number 
/ that the CA in Box 73 encoded into its response r. 

SECOND PREFERRED EMBODIMENT 

In the second preferred embodiment computations are performed 
35 in a multiplicative group modulo n, denoted by , with n 
being the product of two distinct large primes. Since the 
order of the group may only be known to at most the certifying 
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party, the computations in the exponents are modulo a number v 
that is not a proper divisor of the order of 7L* n . For this 
reason, in the blinded certificate issuing protocols that will 
be described, expressions involving div v will show up (recall 
5 that x is equal to x mod v + v (x div v) for x in M) . 

Since multiplications and divisions in are always 
performed modulo n, the operator modn will never be mentioned 
explicitly. So for example w v stands for u? v modn. In case 
other modulo operations are involved, the modulo operator is 
10 explicitly mentioned (as in, for example, c 0 = c + u mod v ) . If 
numbers are chosen from a group or ring, always the smallest 
positive remainder is implied. For instance, w €<r Z* implies 
that w is chosen at random from the subset {1, ...,n-l} 
containing the numbers co-prime with n (in practice, this set 
15 can be taken to be {l, . . . ,n — l}) . 

As will be obvious to those of ordinary skill in the art, 
one can take v to be either composite or prime. 

The exemplary secret-key certificates will, as in the first 
preferred embodiment, all be constructed from Fiat /Shamir 
20 signature schemes by applying the general construction 

technique. The structure of the exposition is similar to the 
exposition in the first preferred embodiment: a detailed 
description of one particular system is presented first, 
together with a variety of issuing protocols, followed by a 
25 description of how the general construction technique can be 
applied to other Fiat/Shamir type schemes. 

1. First Exemplary Secret-Key Certificate. 

A first exemplary secret-key certificate in the second 
preferred embodiment, constructed by applying the general 

30 construction technique to the Guillou/Quisquater signature 
scheme (See, Guillou, L . and Quisquater, J., 
" A practical zero-knowledge protocol fitted to security 
microprocessor minimizing both transmission and memory , " 
Lecture Notes in Computer Science 330, Proceedings of 

35 Eurocrypt *88, Springer-Verlag (1989), pp. 123-128), will now 
be described in detail. 

Key generation means of the KAC: Let v be an element in Z; . 
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A convenient choice for v is to take v a prime that is 
co-prime to (^(n) (the number of elements of Z*) . 

The secret key of the CA is a number x 0 in Z* , and its 
corresponding public key h Q is equal'' to xJJ . Preferably, x 0 is 
5 chosen uniformly at random in Z* . 

The triple (n,v,h 0 ) is made publicly known by the CA. In 
addition/ a hash-function H is made publicly known, which maps 
its arguments to, say, Z 2 * , for some appropriate security 
parameter t. This function should meet the requirements that 
10 are believed to make the Guillou/Quisquater signature scheme 
secure, and is preferably collision-free. 

Certificate verification means: A secret-key certificate on 
a public key h in 7L* n of U is a pair (c, r) in Z 2 * x Z* such that c 
is equal to *H{h, r v (h 0 h)~ c , I) . The number / is as described in 
15 the first preferred embodiment, and as before its 
incorporation is not strictly necessary. 

The secret-key certificate can alternatively be taken to be 
a pair (a,r) in ZJxZJ, In that case, the pair is a secret-key 
certificate on h if r v (h 0 h)~ c is equal to a, where c is computed 
20 as H{h,a, I) . 

As will be clear to those of ordinary skill in the art, this 
secret-key certificate system has been constructed from the 
Guillou/Quisquater identification scheme by applying the 
general construction technique. That is, the certificate is 

25 in effect a Guillou-Quisquater signature on h made with secret 
key (h 0 h) l/v , corresponding to the public key h 0 h. 

Key generation means of U : In a general form, the secret 
key of U can be taken to be a tuple (z u . . . , z k ; x) , where each z t 
is in Z v , x is in Z;, and h is equal to (Ui=i 9V) xVl * < As wil1 

30 be clear to those of ordinary skill in the art, the more 

general form, (zi, . . . , z k ; i lf . . . , x/) , can be considered, such that h 
is equal to n?=i 9? FlLi X V for appropriate exponents v t . It is 
believed to be straightforward for those of ordinary skill in 
the art to apply the disclosed inventive techniques to this 

35 more general form.) Here, are randomly chosen numbers 

in Z* , preferably of large order (which can easily be taken 
care of by taking the prime divisors p and q of n such that 
p— 1 and g— 1 both have a large prime divisor) , All these 
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numbers are made publicly available by the CA, in addition to 
n y v,h 0 and the description ofH. As will be appreciated, any 
integer v x can be used for the key pair of U. From now on, 
for concreteness v x will always be taken equal to v. 
5 For each g { (l<t<Jfc), the CA should preferably know g- /v , in 

order to be able to conduct the issuing protocol: the secret 
key of the CA that corresponds to the public key h t h is the 
v-th root of this number, which is equal to x 0 x nj=i(ft - 
In practice, one may want to use a simpler form. The 
10 simplest form is one in which the secret key of U is a number 
x in Z*, and the public key h is equal to x v . Another simple 
form is one in which the secret key of U is a pair (xi;x 2 ) in 
Z v xZ;, such that h is equal to gl x x\. Both forms allow U to, 
for instance, compute signatures and prove knowledge of his 
15 secret key. (As is well-known, for a key pair of the form 
9V9V no secure protocols for these tasks are known in the 
art.) As will be demonstrated in the flowchart of FIG. 12, 
this second form is of particular importance for the 
construction of restrictive blind signature protocols. 
20 Certificate simulating means: Those of ordinary skill in the 
art may wish to verify that anyone can feasibly generate pairs 
h, (c,r) such that the verification relation holds, by taking h 
equal to h^s 9 for an arbitrary 5 in Z;, and a equal to t v for - 
an arbitrary t in Z; ; the pair (c,$ c t), with c equal to H{h,aJ). 
25 then is a secret-key certificate on h. However, the ability 
to feasibly generate such pairs together with a secret key, 
that corresponds to the public key h according to one of the 
key schemes described in the preceding three paragraphs , 
enables one to forge Guillou/Quisquater signatures. 
30 Before providing exemplary embodiments for various 

certificate issuing protocols, a few examples are provided 
that will help those of ordinary skill in the art to 
appreciate how the described secret-key certificate may be 
used in practice. 

35 1.1. Examples for the first exemplary secret-key certificate. 

Example 1: In this example, it will be assumed that the secret 
key of U is a number x in Z v , and the corresponding public key 
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h is equal to g x . Here, g is a randomly chosen number in Z* , 
preferably of large order, which has been made publicly 
available by the CA. Suppose that user U Y wants to transfer 
an encrypted message m in Z* to U 2 . The encryption scheme 

5 which is used is the ElGamal scheme in the group Z* . From the 
public-key directory, U 1 retrieves the public key h 2 of U 2 , 
and the string (c 2 ,r 2 ). If c 2 is equal to H(h 2 , r%(h 0 h z )~ c \ I 2 ) . then 
14 1 can safely transfer the encrypted message to U 2 . Hereto, 
he generates at random a number s, and transfers the pair 

10 (g',h 2 ™>) to U 2 . If W 2 can decrypt and retrieve m, then he must 
know log 9 /i 2 (as is well-known in the art, this holds under the 
factoring assumption, and for randomly chosen m) . This in 
turn implies that he could not have generated (/i 2 , (c 2 , r 2 )) by 
himself . 

15 Example 2 : In this example, it will be assumed that the 
secret key of U is a number x in Z*, and the corresponding 
public key h is equal to x v . Suppose that U 2 digitally signs 
a message m for U lt using the Guillou/Quisguater signature 
scheme. U x receives from U 2 a pair (c,r) such that c is equal 

20 to H(m,r v h 2 c ) . If the public key /i 2 of iV 2 is listed in the 

public-key directory together with a pair (c 2 ,r 2 ) for which c 2 is 
equal to H(h 2 , r^(h 0 h 2 )~ C2 , 1 2 ) , then the fact that U 2 can compute 
this signature also informs U x that the key pair of U 2 has 
been certified by the CA. These two facts can also be 

25 verified by anyone else, and so the signature can have legal 
significance . 

1.2. First exemplary certificate issuing protocol. 

A variety of protocols for issuing the described secret-key 
certificate, similar to those described in the first preferred 

30 embodiment, will now be described. For explicitness it will 
be assumed in each of these flowcharts that the secret key of 
U is of the simplest form; it is a number x in Z* such that 
the corresponding public key h is equal to x v . Those of 
ordinary skill are believed to be able to straightforwardly 

35 apply the inventive techniques to suit the other types of key 
pairs for U . 

Turning now to FIG. 8, the first flowchart of a secret-key 
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certificate issuing protocol for the second preferred 
embodiment will now be described in detail. As will be clear 
to those of ordinary skill in the art, this issuing protocol 
has the same functionality as the protocol of FIG. 2. 

5 Box 81 first shows the CA generating a secret key x in Z^ 

for use by W. As indicated in the second line, the 
corresponding public key h of U is taken equal to x v . 

Box 82 first shows the CA generating at random a number w 
in Z*. The second line shows the CA computing w v , which is 

10 denoted by a for further reference. The third and fourth 
lines show the CA computing H(h,a,I), which is denoted by c, 
and (x 0 x) c w, which is denoted by r. The CA then transfers the 
secret key x and the pair (c,r) to W, as described by the fifth 
line . 

15 Box 83 first shows U computing his public key h t by setting 
it equal to x v . The second line indicates that U verifies if 
c is equal to the hash-value of the triple {h,r v (h 0 h)' c J) . 

If the equality holds, the pair (c,r) is a secret-key 
certificate on the public key h of U, such that U knows the 

20 secret key corresponding to h. 

As will be clear to those of ordinary skill in the art, if 
the CA knows the prime factorization of n, then in Box 82 it 
can simply take any number a in Z; . Of course, since v-th 
roots are involved, the CA must generate this number from the 

25 set of all v-th powers in Z;,- if v is co-prime to tp(n) then 

this set is equal to Z; ; if, for example, v is twice a number 
that is co-prime to tp{n) , then i>-th roots modulo n exist only 
for the quadratic residues in Z* . 

1.3. Second exemplary certificate issuing protocol. 

30 As in the first preferred embodiment, the need for the CA to 
know the secret key of U can be removed by letting U perform 
part of the computations . 

Turning now to FIG. 9, a flowchart of a secret-key issuing 
protocol that hides the secret key of U from the CA, in the 

35 second preferred embodiment, will now be described in detail. 
As will be clear to those of ordinary skill in the art, this 
issuing protocol has the same f unctionality as the protocol o 



8NSDOCID:<WO 9612362A2> 



WO 96/12362 



PCT/NL95/00350 



46 

FIG. 3. 

Box 91 first shows U generating at random a number x in Z* ; 
this will be his secret key. The second line shows U 
computing the corresponding public key h by setting it equal 
5 to x v . U then transfers h to the CA, as indicated by the 
third line. 

Box 92 first shows the CA generating at random a number w 
in Z* . The second line shows the CA computing w v , which is 
denoted by a for further reference. The third and fourth 

10 lines show the CA computing H(h,a,I), which is denoted by c, 

and x%vj , which is denoted by r 0 .- The fifth line indicates that 
the CA transfers the pair (c, r 0 ) to U . 

Box 93 first shows U verifying whether c is equal to the 
hash-value of the triple (h, t v 0 Kq c , I) . As described by the second 

15 line, if this is the case then U computes r 0 x c , which is 
denoted by r. 

As can easily be verified by those of ordinary skill in the 
art, the pair (c, r) is a secret-key certificate on the public 
key h, such that U knows the secret key corresponding to h . 

20 1.4. Hiding the secret key from the CA. 

Contrary to the first preferred embodiment, the RSA function 
has a trapdoor (i.e., the prime factorization of n) . If the 
CA knows this prime factorization, it can always compute the 
secret key, even if U tries to hide it by using the issuing 

25 protocol of FIG. 9. Nevertheless, it can still make sense for 
U to hide the secret key from the CA, namely, in the case 
multiple secret keys correspond to the same public key and U 
can know only one (or a small fraction of all corresponding 
secret keys) . The following example may help to appreciate 

3 0 this. 

Consider a situation where the secret key of U is a tuple 
(xi,x 2 ; h,h) in Z; x Z; x Z v x TL V , such that h x is equal to g^xl 
and h 2 is equal to g{ 2 x v 2 , where (/ii,/i 2 ) is his public key. As is 
well-known in the art, this public key can be used to make a 
35 one-time signature. The signature of U on a message m in Z* 
is the pair {hm + J 2 mod v, g[ im + h divv x"x 2 ) . A straightforward 
modification of the preceding certificate issuing protocol 
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gets U a secret-key certificate on his public key {hi t h 2 ). 
(The certificate is a pair (c, r) such that c is equal to 
(hi,h 2 ,r v (h 0 h l )~ c , I) , for instance.) Of course, as will be clear 
to those of ordinary skill in the art, to prevent forgery of . 

5 signatures, the number m in the verification relation for the 
signature now must be taken equal to a one-way hash of at 
least the message and the public key, instead of being the 
message itself. Now, even if the CA knows the prime 
factorization, and hence can compute all secret keys 

10 corresponding to {hi,h 2 ), the probability is negligible that it 
can determine the particular secret key known by U; as is 
well-known in the art, the signature scheme of U is 
witness -indistinguishable . This in turn implies that if the 
CA forges a signature of U, using a different secret key, then 

15 the U can compute g\ /v , thereby proving the fraud of the CA. 

If the CA should not have the power to compute any secret 
key at all, the number n must be generated such that the CA 
does not know the prime factors. To this end, the process of 
generating n should be conducted by a trusted secured device 

20 that destroys the prime factors after having generated n, or 
by some other trusted party. 

1.5. Third exemplary certificate issuing protocol. 

As in the first preferred embodiment, there exist many 
secret-key certificates (c,r) on the same public key and so the 
25 CA may choose a particular one and encode information in it. 

Turning now to FIG.* 10, a flowchart of a secret-key issuing 
protocol that hides the secret key from the CA and prevents 
the subliminal channel, in the second preferred embodiment, 
will now be described in detail. As will be clear to those of 
30 ordinary skill in the art, this issuing protocol has the same 
functionality as the protocol of FIG. 4. 

Box 101 first shows the CA generating at random a number w 0 
in Z;. The second line shows the CA computing u/J, which is 
denoted by a 0 for further reference. The third line indicates 
3 5 that the CA then transfers a 0 to U . 

Box 102 first shows U generating at random a number x in 
Z* ; this will be his secret key. The second line shows U 
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computing the corresponding public key h by setting it equal 
to x v . The third line shows U generating at random a number w 
in Z*, and the fourth line shows U computing w v , which is 
denoted by a. Finally, as described in the fifth line, U 

5 transfers the pair (h,a) to the CA. 

Box 103 first shows the CA computing H(h, a 0 a, /) , which is 
denoted by c for further reference. The second line shows the 
CA computing x%w 0 , which is denoted by r 0 . As described by the 
third line, the CA then transfers r 0 to W. 

10 Box 104 first shows U computing c as did the CA in the first 
line of Box 103, The second line indicates that U verifies 
whether aa 0 is equal to r^h^ c . As the third line displays, if 
this is the case then 14 computes r 0 x c w , which is denoted by r. 
As can easily be verified by those of ordinary skill in the 

15 art, the pair (c,r) is a secret-key certificate on the public 
key h t randomized by U , such that U knows the secret key 
corresponding to h. 

It will be obvious to those of ordinary skill that U in Box 
102 could transfer w to the CA, instead of a. In Box 103 the 

20 CA can then compute x%w 0 w itself, into which U now has to 
multiply x c modulo n . This, however, causes an extra 
computational cost for the CA, which now has to compute one 
additional exponentiation in Z^, whereas the computational 
cost for U is virtually not reduced. 

2 5 1.6. Fourth exemplary certificate issuing protocol. 

Turning now to FIG.. 11, a flowchart of a fully blinded 
secret-key issuing protocol in the second preferred embodiment 
will now be described in detail. As will be clear to those of 
ordinary skill in the art, this issuing protocol has the same 
30 functionality as the protocol of FIG. 5. 

As discussed in the first preferred embodiment, for 
convenience the string / will henceforth be omitted. 

Box 111 first shows the CA generating at random a number w 0 
in Z^. The second line shows the CA computing w v 0 , which is 
35 denoted by a 0 for further reference. As described by the 
third line, the CA then transfers a 0 to W, 

Box 112 first shows U generating at random a number x in 
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Z;,- this will be his secret key. The second line shows' U 
computing the corresponding public key h, by setting it equal 
to x v . The third line shows U generating at random a number t 
in Z*, and the fourth line shows U generating at random a 

5 number u in Z v . Using these random numbers, the fifth line 
shows how U blinds a 0 , by computing a 0 t v h%; this number is 
denoted by a for further reference. The sixth line shows U 
computing 7i(h,a), which is denoted by c, and blinding it, as 
described by the seventh line, to c + umo&v; this number is 

10 denoted by c 0 for further reference. As described by line 
eight, U then transfers c 0 to the CA. 

Box 113 first shows the CA computing x%w 0 , which is denoted 
by r 0 for further reference. As described by the second line, 
the CA then transfers r 0 to W. 

15 Box 114 first shows U verifying whether r v 0 ho Co is equal to 

a 0 . As described by the second line, if this is the case then 
U computes r o x c t/i c 0 +udivv , which is denoted by r. 

As will be clear to those of ordinary skill in the art, (c,r) 
is a secret-key certificate on the public key h of U . In 

20 addition, views of the CA in executions of this issuing 
protocol are independent from pairs (h, (c, r)). 

1.7. Fifth exemplary certificate issuing protocol. 

Turning now to FIG. 12, a flowchart of a restrictive blind 
secret-key certificate issuing protocol for the second 

25 preferred embodiment will now be described in detail. This 
protocol is also described and claimed in patent application 
Ser. No. PCT/NL.94 /00179 , but, as will be appreciated, is 
included here (using the present notation) to clearly 
demonstrate that the protocol in effect is a restrictive blind 

30 secret-key certificate issuing protocol. As will be clear to 
those of ordinary skill in the art, this issuing protocol has 
the same functionality as the protocol of FIG. 6. 

The key pair of U must be different from that used until 
now, because the secret key must be a vector of at least two 

35 numbers. For concreteness , the following choice is made: the 
secret key of U is a pair (x; I) in Z; x Z v such that x v g[ is 
equal to h. Here, the CA has generated g 1 by generating at 
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random a (secret) number j/ in Z*, and setting g 1 equal to y v . 

The second number of this pair, /, will be encoded by the CA 
into the secret key of U during the certificate issuing 
protocol, in such a way that U will not be able to change / to 

5 a number V that differs modulo v from /. On the other hand, U 
will be able to generate x by himself uniformly at random in 
Z*, and hence h in effect is generated at random from Z* , 
independently from /. As described before , the number / may 
be related to the identity of U , but can as well contain 

10 unrelated information, such as a credential specification. 

Box 121 first shows the CA generating at random a number w 0 
in Z^ . The second line shows the CA computing w% t which is 
denoted by a 0 for further reference . As described by the 
third line, the CA then transfers a 0 to U . 

15 Box 122 first shows U generating a number x in Z* ; the pair 
(x, /) will be his secret key. The second line shows U 
computing the corresponding public key h, by setting it equal 
to x v g{ . In addition, as displayed in the third and fourth 
lines, U generates two random numbers t in Z* and u in Z v , 

20 which will serve to obtain blinded r and c. The fifth line 

shows U computing aot v {h 0 g[Y , which is denoted by a for further 
reference. As indicated in the sixth line, U then computes 
lt{h,a), which is denoted by c. The seventh line specifies U 
computing c + umodv, which is denoted by c 0 . As described by 

25 the eighth line, U then transfers c 0 to the CA. 

Box 123 first shows the CA computing (x 0 y ; ) c °u;o / which is 
denoted by r 0 for further reference. As described by the 
second line, the CA then transfers r 0 to U . 

Box 124 first shows U verifying whether rl(h 0 g{)~ Co is equal 

30 to a 0 . As described by the second line, if this is the case 
then U computes r 0 x c t{h 0 g[) c+u ^ v , which is denoted by r. 

As can easily be verified by those of ordinary skill in the 
art, the pair (c, r) is a secret -key certificate on the public 
key h of U, such that U knows the secret key corresponding to 

35 h. Although U has perfectly blinded h and (c,r), it is 

unfeasible for him to completely blind the secret key. The 
secret key of U is a pair (x; V) such that x v g[ is equal to h, 
and if (c,r) is to be a secret-key certificate on h then /' is 
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unavoidably equal modulo v to the number / that the CA in Box 
123 encoded into its response r. 

. 1.8. More than one receiving party. 

As in the first preferred embodiment, the protocols displayed 
5 in FIGS. 11 and 12 can also be used by the CA to issue the 

secret-key certificate to U and an additional party T that is 
substantially under control of the CA, such that: U will get 
to know the public key and the secret-key certificate on the 
public key; and the secret key corresponding to the public key 
10 is shared between U and T in such a way that neither of U and 
T can determine it. 

One possible such use, based on the protocol of FIG. 11, 
will now be described. The secret key used that will be used 
for U by the CA now is Ix 0 (the public key still is x%) , where 
15 / is known by T but not by W; U only knows I v . The issuing 
protocol between the CA and U as described by FIG. 11 now 
takes place, where the CA now computes in the first line of 
Box 113 the number r 0 as (x 0 I) c<, w 0 . As will be clear to those of 
ordinary skill in the art, T at the end of the issuing 
20 protocol knows /, and U knows z, and the certified public key 
is equal to (Ix) v . As will be appreciated, T does not need to 
participate in the secret-key certificate issuing protocol due 
to the initial set-up in which the CA only makes / known to T. 
In patent application Ser . No. PCT/NL94 / 00179 , techniques are 
25 detailed and claimed for T and U to conduct a certificate 
showing protocol following the issuing protocol. 

Other variations of the issuing protocol, for the case the 
certificate is issued to U and T in the manner described in 
the preceding paragraph (such as a variation in which T and U 
30 end up with a certified public key of the form g[x v ) , are 
believed to be obvious to construct for those of ordinary 
skill in the art. 

2. Second Exemplary Secret-Key Certificate. 

As in the first preferred embodiment, a variety of other 
35 secret-key certificates will now be described, each of which 
is constructed from a Fiat/Shamir type signature scheme by 
applying the general construction technique. 
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A second exemplary secret-key certificate in the second 
preferred embodiment, constructed by applying the general 
construction technique to the Okamoto signature scheme (See, 
Okamoto, T., Section 3.2./3.3. and Section 6 in 
5 " Provably Secure and Practical Identification Schemes 

and Corresponding Signature Schemes ," Crypto '92, Lecture 
Notes in Computer Science 740, Springer-Verlag (1S93), pp. 
31--53), will now be described. 

Key generation means of the KAC : The secret key of the CA is 
10 a pair (x x ; x 2 ) in Z v x Z* , and the corresponding public key h 0 
is equal to g Xx x\ , where g is an element of large order in Z* . 

The tuple (g,v y h 0 ,n) is made publicly known by the CA. The CA 
also makes publicly known a hash- function H, which maps its 
arguments to, say, Z 2 * / for some appropriate security 
15 parameter t~ This function should meet the requirements that 
are believed to make the Okamoto signature scheme secure. 

Certificate verification means: A secret-key certificate on 
a public key h in Z^ of U is a triple (c,r 1 ,r 2 ) in Z 2 * x Z v x Z; 
such that c is equal to H(h, g ri r»(h 0 h)- c , I) . 
20 Alternatively, the secret-key certificate can be taken to be 
a triple (a,^,^) in Z; x Z; x Z; . In that case, the triple is a 
secret-key certificate on h if g rx r v 2 {h 0 h)' c is equal to a, where c 
is computed as H(h, a, /) . 

The certificate is in effect an Okamoto signature on h made 
25 with a secret key that corresponds to the public key h 0 h. 

Key generation means of U : The discussion of key pairs for 
U provided earlier with respect to the first secret-key 
certificate for the second preferred embodiment, applies here 
as well. (As will be clear to those of ordinary skill in the 
30 art, the symbols Xi,x 2 chosen here for convenience, do not 
refer to the symbols in that discussion.) 

Certificate issuing means: Those of ordinary skill in the 
art are believed to be capable of straightforwardly applying 
(a) the inventive techniques for the issuing protocols of 
35 FIGS. 8 to 12, and (b) the inventive technique to issue the 
secret-key certificate to U and an additional party T, to 
construct similar certificate issuing protocols for the 
present secret-key certificate. 
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3. Third Exemplary Secret-Key Certificate. 

A third exemplary secret-key certificate in the second 
preferred embodiment, constructed by applying the general 
construction technique to the Fiat/Shamir signature scheme 
5 (See, Fiat, A. and Shamir, A., " How to prove yourself: 

practical solutions to identification and signature problems , M 
Proceedings of Crypto '86, Lecture Notes in Computer Science 
263, Springer-Verlag (1987), pp. 186--194) , will now be 
described . 

10 Key generation means of the KAC : The secret key of the CA is 
a tuple (x!,...,Xfc), where each z< is in Z; . The corresponding 
public key is (h u ...,h k ), where each hi is equal to (x" 1 ) 2 . 
(Instead of squares, other powers can be used as well.) 

The tuple . . . , h k , n) is made publicly known by the CA. The 

15 CA also makes publicly known a hash-function H, which maps its 
arguments to, say, Z 2 « < for some appropriate security 
parameter /. This function should meet the requirements that 
are believed to make the Fiat/Shamir signature scheme secure. 
Certificate verification means: A secret-key certificate on 

20 a public key (h'^ . . . , h' k ) of U, where each h\ is in Z^, is a tuple 
(c.r!,...,^), where c is in Z 2 « and each r t is in Z; , such that c 

is equal to H( (h'^ . . . , h' k ), (r^IIc^iMj '"iIl^iMJ) )■ Here - the 

index j runs from 1 to k, and (c^, - • • , c**) is the binary vector 
consisting of the t-th group of A: bits of the number c. The 

25 notation rU ; = i h j^j denotes the product taken over all numbers 
(hjh'j) with j such that the bit c„ (this is the j-th bit in the 
:-th group of k bits of the number c) is equal to one. 

One can consider the public key . . . , h k ) of the CA to be a 
vector h 0 . and the public key (h\, . . . , h' k ) of U to be a vector h. 

30 The secret-key certificate is in effect a Fiat/Shamir 

signature on h made with a secret key that corresponds, under 
the Fiat /Shamir signature scheme, to the public key h 0 h, where 
the vector multiplication h 0 h is defined by pairwise 
multiplication: h 0 h is equal to (hih^, . . . , h k h' k ) . 

35 Key generation means of U : The key pair of U is of the same 
type as that of the CA . More precisely, the secret key 
corresponding to the public key . . . , h' k ) , denoted by h 9 , is a 
vector (xi,...,x' fc ) such that (x^)" 2 ^ h[ . 
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Certificate issuing means: Those of ordinary skill in the 
art are believed to be capable of straightforwardly applying 
the inventive techniques for (a) the issuing protocols of 
FIGS. 8 to 12, and (b) the inventive technique to issue the 
5 secret-key certificate to U and an additional party T, to 
construct similar certificate issuing protocols for the 
present secret-key certificate. 

4. Fourth Exemplary Secret-Key Certificate. 

Yet another Fiat /Shamir type signature scheme is the 
10 Feige/Fiat/Shamir signature scheme (See, Feige, U., Fiat, A. 
and Shamir, A. , " Zero-knowledge proofs of identity , w Journal 
of Cryptology 1 (1988), pp. 77 — 94). This scheme is a 
modification of the Fiat/Shamir scheme. Since the application 
of the general construction technique to this scheme is highly 
15 similar to the construction of the third exemplary secret-key 
certificate in the second preferred embodiment, a detailed 
description is omitted here. Again, for (a) each of the 
issuing protocols of FIGS. 8 to 12 , and (b) the inventive 
technique to issue the secret-key certificate to U and an 
20 additional party T, a similar issuing protocol for the present 
secret-key certificate can be constructed straightforwardly in 
this manner. 

5. Fifth Exemplary Secret-Key Certificate. 

As in the first preferred embodiment, it will now be 
25 demonstrated that certain variations of the general 

construction technique can be used as well. Yet another 
exemplary secret-key certificate in the first preferred 
embodiment, constructed by applying a variation of the general 
construction technique to the Schnorr signature scheme, will 
30 now be described in detail. 

Key generation means of the KAC: This is the same as in the 
description of the first secret-key certificate. 

Certificate verification means: A secret-key certificate on 
a public key h in Z* of U will now be taken to be a pair (c, r) 
35 in Z 2 * x Z* such that c is equal to H(h,r v h~ c , I) . 
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The secret-key certificate can alternatively be taken to be 
a pair (a,r) in Z* x Z* such that r v h~ c is equal to a, where c is 
computed as 7i(h, a, /) . 

Key generation means of U: In general, for the modified 

5 secret-key certificate to be secure, the public key of U must 
be defined as a product gl l - • • g^h^^zl . (Those of ordinary 
skill in the art may wish to consider an even more general 
form, (xi,. . Xfc + i,zi, . . . such that h is equal to 

ho 1 " fl II*=i 9? nl=i z i % for appropriate exponents Vi . ) As with the 

10 first secret-key certificate, gi, -,9k are randomly chosen 

elements of large order in Z*, that are published by the CA in 
addition to v, h 0 , n, and the description of H. At most the 
CA should know the v-th root of each of <h,...,<fc. 

In practice, one may want to use a simpler form of key pair. 

15 The simplest form is one in which the secret key of U is a 
number x in Z* , and the public key h is equal to (h 0 ) x , and h 
may not be equal to 1. Another simple form is one in which 
the secret key of U is a pair (x 1 ;x 2 ), such that h is equal to 

20 As in the first preferred embodiment, all the issuing 

techniques provided for the first secret-key certificate in 
the first preferred embodiment can be applied straightforward 
to construct issuing protocols for the modified secret-key 
certificate. It is believed that those of ordinary skill in 

25 the art are easily capable of doing so by studying the 
inventive techniques in conjunction with the flowcharts. 

Instead, the following two remarks are made here, to help 
those of ordinary skill in the art appreciate the advantages 
of applying the general construction technique over applying 

30 the present variant thereof. 

(1) Consider the restrictive blind secret-key certificate 
issuing protocol for the present secret-key certificate, which 
is similar to the flowchart of FIG. 7; if the secret key of U 
is a pair (i\x) in Z v x Z v , and the public key h is equal to 

35 h J o9i' then the number I/xmodv can be encoded by the CA into 
the secret key (U will not be able to modify this quotient) . 
However, for key pairs for U of this form, no secure signature 
schemes and proofs of knowledge are known in the art. On the 
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other hand, using a key pair for U such ^hat the secret key is 
a pair (J; x) in Z v xZ*, and the public key is h J 0 x v , has the 
problem that the information that has been encoded into the 
secret key by the CA, cannot be efficiently reconstructed from 

5 I and x. Hence, in order for the issuing protocol to have 
practical value, one must take the secret key of U to be a 
triple (/i,7 2 ;x) such that h is equal to h J 0 l g[ 2 x v . Th: s is less 
efficient than the key pair used in the restrictive blind 
issuing protocol for the first secret-key certificate. 

10 (2) As will be appreciated, the security of the systems 

constructed using the general construction technique is closer 
related to the security of the underlying Fiat /Shamir 
signature scheme. 

Conclusion . 

15 This concludes the detailed descriptions of two preferred 
embodiments. While these descriptions of the present 
invention have been given as examples, it will be appreciated 
that various modifications, alternate configurations, and 
equivalents may be employed without departing from the spirit 

20 and scope of the present invention. For example, there are 
many essentially equivalent orders to evaluate expressions; 
ways to evaluate expressions; ways to order expressions, 
tests, and transmissions within flowchart boxes; ways to group 
operations into flowchart boxes; and ways to order flowchart 

25 boxes. The particular choices that have been made here are 
merely for clarity In exposition. 

Certain variations and substitutions may be apparent to 
those of ordinary skill in the art. Although various such 
variations and substitutions have been indicated and sometimes 

30 described in detail in the text, this may be more fully 
appreciated in the light of the following examples. 

First, the exemplary secret-key certificates that have been 
described are derived from Fiat/Shamir type signature schemes 
by the general following construction technique: denoting the 

35 public key of U by h, and that of the CA by h 0 , a 

secret-certificate on h in effect is a signature of the 
underlying Fiat /Shamir type on the message h made with a 



BNSDOCID:<WO 9612362A2> 



WO 96/12362 ^ PCT/NL95/00350 

\ » 57 

secret key that corresponds to public key h 0 h. It has already 
been shown, at the end of the description of the first 
preferred embodiment, that variations on the general 
construction technique may be applied as well. As will be 
5 appreciated, the particular form h 0 h in the general 

construction technique is not essential. Taking, for example, 
the form h 0 h k for a fixed integer k different from 1 would 
obviously work as well. The essence of the general 
construction technique is that the secret-key certificate is 
10 constructed from any Fiat /Shamir type signature scheme by 

letting the certificate in effect be a signature on the public 
key of U , where the signature is of the underlying Fiat/Shamir 
type signature scheme and made with a secret key that 
corresponds, under the Fiat /Shamir type signature scheme, to a 
15 public key which is a suitable mathematical function of the 
public key of U and the public key of the CA. 

Second, hierarchic certification can be implemented with 
secret-key certificates. As will be clear to those of 
ordinary skill in the art, U in turn can use his certified key 
20 pair to issue a secret-key certificate to another party, and 
so on. In this way, a hierachical certification tree can be 
constructed: each node in this tree can be considered to be a 
pair consisting of a public key and a secret-key certificate 
on the public key, where a parent node certifies the key pairs 
25 of its child nodes by issuing a secret-key certificate on the 
public key of each child node, computed by using a secret key 
corresponding to the public key of the parent node. If, for 
instance, a decryption can be performed by a party associated 
with a node in the tree, then this party must know the secret 
30 key corresponding to the public key in that node; this in turn 
implies that the secret-key certificate must have been 
computed by the party associated with the parent node, and so 
this party in turn knows the secret key corresponding to the 
public key of the parent node; hence, the secret-key 
35 certificate of the parent node must have been computed by the 
party associated with the parent node of the parent node; and 
so on, all the way to the root node. 

Third, the secret-key certificate technique can be used to 
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construct secure digital signature schemes. To sign a 
message, the signer party, which has a first secret key and a 
matching first public key, first generates independently at 
random a one-time secret key and a matching one-time public 

5 key, where the word "one -time" is used only to emphasize that 
these keys will be used only once by the signer party. The 
signer party then computes a secret-key certificate on the 
one-time public key with respect to the first public key. It 
can do this because it knows the first public key. It then 

10 signs the message with respect to the one-time public key, 

which it can do because it knows the one-time secret key. The 
resulting signature of the signer party on the message 
consists of the one-time public key, the secret-key 
certificate on the one-time public key, and the signature on 

15 the message with respect to the one-time public key. To 

verify the signature, the certificate verification means are 
used to verify the secret-key certificate, and the signature 
on the message is verified by using the one-time public key. 
The signer party can generate independently at random a new 

20 one-time secret key and matching one-time public key each time 
that it has to sign a message. In effect, this method of 
constructing a secure digital signature scheme using the 
secret-key certificate issuing technique is the same as that 
applied in the example of hierarchic certification, disclosed 

25 in the preceding paragraph. 

It will also be obvious to those of ordinary skill in the 
art how parts of the inventive techniques and protocols 
disclosed here can be used to advantage. 
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WHAT IS CLAIMED IS; 

1. A cryptographic method wherein a first party issues a 

certificate, called a secret-key certificate, to a second 
party, the method comprising the steps of: 

generating, for use by the first party, a first secret 
key, unknown at least in part to the second party, and 
a corresponding first public key; 

generating, for use by the second party, a second 
secret key and a corresponding second public key; 

issuing by the first party to the second party, in a 
certificate issuing protocol, a secret-key certificate 
certificate corresponding to the second public key 
15 according to a publicly verifiable relation, the 

secret-key certificate being a digital signature of 
the first party on the second secret key, and the 
second party being able to feasibly generate without 
assistance of the first party public keys and 
corresponding secret-key certificates. 

A method as in claim 1, where the second public key, the 
corresponding secret-key certificate and information 
related to the second party are listed in a public-key 
directory. 

t . A method as in claim 1, where the second party uses the 
second secret key to perform at least one of the followi 
cryptographic actions, namely, digital signing; proving 
knowledge of a secret key corresponding to the second 
public key according to the public-key scheme, without 
revealing the second secret key; decrypting a message that 
is encrypted with the second public key; or issuing a 
secret-key certificate corresponding to a public key. 

1. A method as in claim 1, where the first party signs a 
message for a third party by: 

generating at random a one-time secret key and a 
corresponding one-time public key; 
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computing a secret-key certificate corresponding to 
the one-time public key, by applying the first secret 
key ; and 

computing a digital signature on the message, with 
respect to the one-time public key, by applying the 
one-time secret key, 

the digital signature of the first party on the message 
consisting of the one-time public key, the secret-key 
10 certificate corresponding to the one-time public key and 

the digital signature on the message that has been made 
with respect to the one-time public key. 

5. A method as in claim 1, where the second party in the 
15 certificate issuing protocol does not reveal the second 

secret key to the first party. 

6. A method as in claim 1, where the second party in the 
certificate issuing protocol blinds the second secret key, 
the second public key and the corresponding secret-key 
certificate . 

7. A method as in claim 1, where the second party in the 
certificate issuing protocol blinds the second public key 
and the corresponding secret-key certificate, but not a 

25 pre-determined non-constant function of the second secret 

key . 

8. A method as in claim 1, where the second party comprises a 
first sub-party, that acts in the interest of the first 

^ o party, and a second sub-party, the second secret key not 

being known to either one of the two sub-parties. 

9. A method as in claim 1, where the secret-key certificate 
is a digital signature key of the Fiat /Shamir type, made 
with respect to a public key that is a combination of the 

35 first public key and the second public key. 

,10. A method as in claim 9, where the digital signature is a 
Schnorr digital signature. 
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11. A method as in claim 1, where the second secret key 
represents a set of credentials of the second party. 

12. A method as in claim 1, where the secret-key certificate 
represents a credential issued by the first party to the 
second party. 

13. Apparatus for implementing a cryptographic system in which 
a first party issue- a certificate, called a secret-key 
certificate, to a second party, the apparatus comprising: 



20 



first key generation means that, on being given as 
input at least a security parameter, outputs a pair 
consisting of a first secret key and a corresponding 
first public key, for use by the first party; 

15 second key generation means that, on being given as 

input at least a security parameter, outputs a pair 
consisting of a second secret key and a corresponding 
second public key, for use by the second party; 
certificate verification means that, on being given as 
input the first public key and a pair consisting of a 
third public key and a presumed secret-key certificate 
corresponding to the third public key, responds 
affirmatively or negatively, depending on whether the 
presumed certificate corresponds to the third public 
key or not; 

certificate issuing means that, on being given as 
input the first secret key, the second secret key and 
the second public key, outputs a secret-key 
certificate corresponding to the second public key, 
the secret-key certificate being a digital signature 
of the first party on the second secret key; and 
certificate simulating means that, on being given as 
input the first public key, outputs a fourth public 
35 key and a secret-key certificate corresponding to the 

fourth public key, the probability distribution of the 
output of the certificate simulating means being 
substantially indistinguishable from the probability 
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distribution that applies when a public key is 
generated by the second key generation means and a 
corresponding secret-key certificate is generated by 
the certificate issuing means. 
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generated by anyone. However, 
triples consisting of a secret 
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corresponding to the public key, 
can only be generated when the 
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Also described are applications 
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public-key directories and to 
restrictive blind issuing protocols. 
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